This opens your own email app. Nothing is sent from this website, and this website collects nothing about you.
You must be 18 or over. I do not take on projects from minors, so please do not send an email if you are under 18.
My email provider handles the message in transit, as it would any email.
CASE STUDY
Example buildCode RescueYou built it with AI over a weekend and it works. This is what it takes before it can safely carry a business.
This is an example build. Tavzuran is a new studio with no client work to show yet. This page describes how the project would be scoped and built — the same thinking you would get on a real one. Nothing here is a past client, and no number on this page is a result.
The price follows the feature list. The number above buys everything scoped on this page. Take features out and it comes down — the shortest route to a smaller number is a shorter list, and deciding what to drop is what the free call is for.
THE SITUATION
Someone built a working product with an AI tool — Cursor, Lovable, Bolt, v0, Replit, or a long conversation with a chatbot. That is a genuine achievement, and the thing usually does what it was asked to do. The demo is real.
Then it meets reality. A second user signs up and can see the first one's records. The database slows down at a few thousand rows because nothing is indexed. A key that should live on a server is sitting in the JavaScript every visitor downloads. There is no way to run the project locally, so every fix is made in production and hoped over.
None of that is an argument against building with AI — it is how this studio works too. The difference is that generated code has never been read by someone who will be called when it breaks. That reading is the job.
VERSION ONE
Every item here earns its place by being something a real user would miss on day one.
Before touching anything: what is exposed, what breaks under load, what cannot be recovered. Delivered as a plain-language document with each item priced and ranked by risk. You can hand it to another developer and never speak to me again — it is yours either way.
Keys moved out of anything a browser downloads and rotated, because a key that has been public is burned. Then the access rules: every table and every endpoint checked against a second account that should not be allowed in.
The project runs on a fresh machine from a single command. Deploys happen from a repository rather than a laptop. Automated tests around the two or three flows that touch money or personal data — not full coverage, which nobody maintains.
Indexes where the slow queries are. Constraints so the rules live in the database instead of in hope. Migrations, so the schema has a history. Backups, and one restore actually performed to prove they work.
What was changed and why, what is still owed, and what it would cost. If you want to keep building with AI afterwards, guidance on where that goes well and where it reliably does not.
DELIBERATELY NOT IN V1
Not because these are bad ideas. Because each one is designed better once the first version has told you something.
UNDER THE HOOD
HOW IT RUNS
Read everything and write the audit. Close whatever is actively dangerous while it is still being written.
Access rules, secrets rotated, database constraints and indexes, backups proven by a restore.
Local setup, deploys, the small test suite, and the handover document.
THE HARD PART
Every build has one problem that decides whether the rest of it matters. This is that problem, written out.
The instinct on opening a generated codebase is to rewrite it. That is almost always the wrong call. The code works — people are using it — and a rewrite trades a running product for three months of silence and a new set of bugs.
The real work is triage. Roughly, three piles: things that are dangerous and must change this week, things that are merely ugly and can wait forever, and things that look wrong but are actually fine. Most generated code is in the third pile. A page with repeated markup offends an engineer and costs the business nothing. An admin endpoint with no authentication check costs the business everything, and looks identical in a screenshot.
So the order is fixed and it is not negotiable: first stop the bleeding — keys out of the browser bundle, access rules on the database, a backup that has been restored at least once. Then make change safe — a way to run it locally, a way to deploy that is not someone's laptop, tests around the two or three flows that carry money. Only then does anyone get to have an opinion about file structure.
The failure I design against is the rescue that becomes a rewrite. It starts honestly — this function is unclear, I will tidy it — and four weeks later the business has paid for a codebase that does exactly what the old one did. Every change in the first fortnight has to be something you could explain to the owner in one sentence, in terms of risk removed.
BEFORE A PRICE EXISTS
A quote given without these answers is a guess. These are the questions that actually move the number.
AFTERWARDS
Agreed before the build starts, so there is something to judge it against other than whether it looks nice.
BEFORE YOU START
This one is quoted from the audit, not before it. The audit is fixed-price and is useful on its own; the repair is quoted once there is a list. What moves the number is how much of the data is already public, whether payments are involved, and whether anyone is relying on the thing while the work happens.
Websites and apps start at ₹20,000*. Final pricing depends on features and project scope. Third-party costs — cloud hosting, domains, external libraries, APIs, app-store fees and any other paid service — are billed separately and are not included.
KEEP LOOKING
The two or three weeks between the app being finished and people being able to install it — rejections, signing keys, store listings and the paperwork.
Read the case study WebsiteYour catalogue lives on Instagram, and you cannot send that to a corporate buyer or a bank. This is the address that is actually yours.
Read the case study Mobile AppMenu, cart, live order tracking and a simple kitchen dashboard for a multi-outlet restaurant.
Read the case studyTell us what you're thinking. We'll figure out the next step together.
Free 20-min idea call · No obligation