Idea, AI-built or agency-built: how to get across the gap

1. The gap

A mockup is quick to draw. An AI tool gives you a working prototype faster still.

Getting it to real users who rely on it every day is the hard part. That is the gap.

The path usually looks like this:

1. Idea. You know the problem and who has it.
2. Mockup. Pictures of the screens. Nothing works yet.
3. Prototype. Something that runs and demos well, as long as you drive it.
4. The gap. Real users arrive and do things the demo didn’t. Data goes missing, two people use it at once, a change in one place breaks another.
5. A product users rely on. It holds up, it’s safe with their data, and a change in one place doesn’t break another.

Step four is where products tend to get stuck. Not because the idea was wrong, but because everything up to step three is about how it looks, and step four is about how it holds. It’s invisible in a demo, so it’s easy to underestimate.

Crossing it takes engineering time and money. This guide covers the parts you control: what to check, what to own and how to judge progress.

2. Where are you starting from?

Go to the section that fits. If two fit, read both.

You have an idea or a mockup (section 3) if:

• you can describe the problem, but nothing runs yet;
• you’ve looked for software that does this and found nothing that fits;
• the process today lives in email chains, paper forms or a spreadsheet.

You built it with AI tools (section 4) if:

• you, or a freelancer, made it with a tool like Lovable, Bolt, Replit, Cursor, v0 or Base44;
• it works in the demo, but real users break it;
• every fix seems to break something else.

An agency or a previous team built it (section 5) if:

• the product exists and people use it;
• every change takes too long, costs too much, or never quite does what it should;
• you’re thinking of changing supplier, or you already have.

3. If you have an idea or a mockup

Is it worth building?

If you’ve looked for software that does this and found nothing, or only tools built for companies ten times your size, there are two possible reasons. The process may be specialised, and the people who know it have never had an engineer to build it with. Or few people will pay for it. The first check below is how you tell them apart.

Before you spend money, check three things:

• The pain is real and regular. Someone loses time or money to it every week, not once a year, and would pay to stop.
• You can name the people who have it. Not “small businesses”, but “site managers on construction jobs who do inspections on paper”.
• Someone on your side can say what “correct” looks like. This matters more than the sector. If nobody can judge whether the software is right, nobody can build it right.

The smallest version real users can try

Don’t build the whole thing. Find the one step in the process that costs the most, and build the first version around that. Keep everything else as it is for now: the spreadsheet, the email, the paper form.

The test: can the people who do the work use it on a real job and tell you what’s wrong? If it needs several other features before anyone can try it, it’s too big.

What to have ready before you talk to anyone who builds

You need three things, in your own words, not software terms:

1. The problem. Who does what today, step by step, and where it goes wrong.
2. Who has it. The actual people who will use the product, and what they’re doing when they use it.
3. What good looks like. How you’d judge the first version. What would make you say “yes, that’s right”.

Questions to ask any builder

• What will the first version do and not do? Can that be written down, item by item?
• How many weeks until real users can try it, and how often will you see it working?
• What happens to the price if the plan changes halfway through?
• Whose name will the code and the cloud accounts (the accounts that pay for and run the servers) be in?
• Can you stop, and with how much notice?
• Who actually does the work, and will you talk to them?

If the answers are vague, the work will be too.

4. If you built it with AI tools

The fix loop

You ask the tool to fix one thing, and something else breaks. You fix that, and the first thing breaks again. Nobody, the tool included, can say why.

This isn’t a mistake you made. These tools are good at a first version and bad at a twelfth. They build whatever you ask on top of whatever is there, and they rarely tidy up what exists. Each feature is added on its own, so each change reaches into all the others.

The tool was the right first step. Holding up with real users is the second, and needs a different kind of work.

Five signs it won’t hold up with real users

1. It demos well, but users try it once and leave. The demo path works; the paths real people take don’t.
2. Every change breaks something else. A sign that nothing holds the features together.
3. Secrets are in the code. A customer’s details, a password or a key (a kind of password one system uses to talk to another) are written straight into the code, where anyone who has the code can read them.
4. It runs in one place only. No test copy to try changes on safely, no backups, nothing watching it, and nobody is sure what happens when two people use it at once.
5. You can’t tell whether what it shows is right. Users stop trusting it the moment they notice.

Screens that look finished are often the most fragile part, not the safe one.

Keep and harden, rebuild part, or start again

Keep and harden (make it hold up under real use) when the product mostly works and users like the screens. Keep what’s there and add what’s missing underneath: secrets out of the code, sign-in and roles (who may see and change what) set up properly, each customer’s data kept apart, tests (automatic checks that run on every change and catch breakages before users do), backups and monitoring (something that alerts you when it goes wrong).

Rebuild part when one area causes most of the breakage. Usually that’s the core: the part every feature should run through but doesn’t. Rebuild that one core, move the features onto it, and keep the screens where they work. After that, the next feature is a small change, not a risk, and you can often keep using your AI tool to add it.

Start again only when there’s little worth keeping and fixing it would cost more than building it fresh. Ask for the reasons in writing before you agree to start again.

Whoever you ask, insist they read the actual code before recommending any of the three.

5. If an agency or a previous team built it

It works, but

It’s too slow (every change takes months), too expensive (every invoice is bigger than the last), or not good enough (it never quite does what it should).

Common signs:

• a small change is quoted at weeks and charged as a change request (a formal, separately priced request to alter agreed work);
• the plan was fixed in the contract, so learning something new costs extra;
• nobody on your side can tell whether what was built is any good;
• you’re paying for a team you can’t see.

What you must own before you change supplier

Before you give notice, make sure these are in your hands, not just “available on request”:

• The code. The full source code (the written instructions that make up the software) in a repository you control (where code is stored with its history; GitHub is the common one).
• The cloud accounts. They should be in your company’s name, with you as the owner, not the agency.
• The data. Your users’ data, and a way to get a full copy of it.
• The documentation. How the system is set up, how to run it and why it was built the way it was. If none exists, ask for it now, while the people who know are still there.

If any of these is in the agency’s name, move it to yours first. It’s much harder after the relationship ends.

Taking it over without starting again

A good new team reads what you have, keeps what works and fixes where the real problem is. Often it’s one part holding everything else back, not the whole thing. It needs from you: access to the code and accounts, whatever documents exist, and regular time from whoever decides what the product should do. You don’t need engineers on your side.

If someone has quoted to rebuild or take over, get a second opinion before you sign: are the price and timeline realistic, and what does it leave out?

6. The three usual routes, honestly

Building it yourself, with AI tools. Right when you’re testing whether anyone wants the product, and a demo is enough to find out. Fast, cheap, full control. It costs your own time, and gets harder to keep right once real users and their data depend on it, unless someone checks for the signs in section 4.

Hiring your own engineers. Right when the software is the business and you’ll need people on it for years. Most control, and the knowledge stays in-house. It costs time: finding, hiring and managing engineers takes effort, and if you can’t judge their work, make your first hire someone senior you trust.

An agency. Right when the job is well defined, the specification (the written description of what to build) won’t change much, and you want a team to deliver it. You get a ready team without hiring anyone, and a fixed price suits a fixed scope. The cost is usually control, though it varies by contract: ask whether the plan is fixed and how changes are charged.

Pick the route that matches where you are, and change when you reach the next stage.

7. What to own from day one

Whoever builds it, these should be in your company’s name from the first day, not handed over at the end:

• The code, in your own repository (for example, your own GitHub account).
• The cloud accounts that run the product, with your company as owner and the bills in your name.
• The data, in your accounts, with backups you can reach.
• The passwords and keys to every service the product uses, stored safely and not in the code.
• The documentation, tested by someone who didn’t write the system, plus a written record of the big design decisions and why they were made.

8. How to judge progress

Judging progress takes three habits, not reading code.

See it working every week. Not a status report or a percentage complete: the product itself, running, doing something it didn’t do last week. Ask to see it running, live or recorded, before each check-in, so you arrive with questions.

Nothing counts as done until you say yes. Agree in writing, item by item, what “done” means before work starts. Then “done” means you’ve seen it and agreed.

Be able to stop after any week. If you can’t stop without a long notice period or a penalty, you lose your easiest way to hold a builder to account.

9. A next step, if it helps

If you know what you want built, we’ll scope it for free: share what you have, we’ll tell you what the first version covers and how many weeks it takes, and you approve the scope before paying anything. Mykola Vorobiov, our senior architect with 25 years building software, leads the engineering, and you can stop any week. Get your first version scoped, free. If you’re still deciding whether to build at all, book a CTO Hour: one hour with Mykola to work out what to build, for $575CAD $800£425€500. If you build with us within 30 days, the hour’s price comes off your first week.