Agency, freelancer, fractional CTO or AI app builder: who should build your app?

Hire a freelancer when the job is small and clearly defined, and someone technical can check their work. Hire an agency or studio when you need design, build, testing and launch handled by one accountable team. Bring in a fractional CTO when you need someone senior to own technical decisions over years. Use an AI app builder to make a clickable prototype you can test with customers, not a product you’ll run a business on.

That fourth option is new, and it’s the one founders now ask us about most. A fractional CTO is a part-time chief technology officer, usually working a few days a month across several companies. Which route you pick matters less than one thing: whether your builder’s goals match yours. The wrong partner, in any model, will drag you like an anchor. Here’s how to choose, from a studio that will tell you when you don’t need us.

What are your four options?

A freelancer

A freelancer is one person, usually a specialist: a designer, a mobile developer or a backend engineer. You brief them, they build, and you check the work. Good ones are fast and direct, with no account managers in between.

An agency or studio

An agency is a team. A typical project has a designer, two or three engineers, a tester and someone running delivery. You buy an outcome rather than hours, and the agency carries more of the risk. That’s especially true when the price is fixed.

A fractional CTO

A fractional CTO is a senior technical leader you share with other companies. They set the architecture, hire and manage engineers, review suppliers and talk to investors. They rarely build the product themselves.

A vibe-coded app

“Vibe coding” means describing what you want to an AI tool and letting it write the code. Lovable, Bolt, Replit and Cursor are the familiar names. The new part is who’s driving: often a founder with no engineering background, accepting whatever the tool produces.

The word that matters across all four is architecture. Architecture means the big structural choices: what the app is built with, where data lives and how the parts talk.

How do they compare on cost, risk and speed?

Day rates vary too much to quote usefully, so we’ll compare shapes rather than numbers.

The row founders skip is “who owns architecture”. Someone always does, whether or not you’ve named them. With a vibe-coded app, the honest answer is that nobody does. The tool made thousands of decisions, and no person on your side can explain them.

Why do vibe-coded apps look so good at first?

Because the first 80% is the part these tools are best at. Ask for a booking app and you’ll have screens, buttons and a login page by lunchtime. It looks finished. For a founder who’s been quoted months and tens of thousands of pounds, that feels like a revelation.

What you’re seeing is the front of the shop. The hard work in software sits behind it. Who can see which data? What happens when two people book the same slot? How do refunds work? None of that shows up in a demo.

Where do vibe-coded apps go wrong?

Security

AI tools write code that runs. They don’t reliably write code that’s safe. Veracode’s 2026 GenAI code security report tested more than 100 models on real coding tasks. On average, only 56% of what they produced passed its security tests. That’s barely changed since Veracode first ran the tests.

Data

Your customers’ data is where a security slip becomes a legal problem. In 2025, a researcher scanned 1,645 apps from Lovable’s public showcase. He found 170 whose databases could be read by anyone, including names, emails and payment details. His write-up of CVE-2025-48757 traces it to missing database access rules. Lovable disputes that it was the platform’s fault, saying each app’s owner is responsible for its data. That’s precisely the point. If you published the app, it’s your responsibility.

Control

AI tools act with confidence, even when they’re wrong. In July 2025, Replit’s coding agent deleted a live production database during a code freeze. It had been told not to make changes. Replit apologised and added safeguards. But a tool can only stop mistakes it knows to look for.

Maintainability and scaling

Each prompt patches the code a little further. After a few hundred, you have an app nobody designed. Fixing one bug breaks two others, and the tool starts going round in circles. Shortcuts that work for 20 test users fall over at 2,000.

Nobody who understands the code

This is the one that catches founders out. When something breaks at 11pm on launch night, who do you call? Hand that code to an engineer and they’ll need weeks just to read it. Often their advice is to start again.

When is a vibe-coded app fine?

More often than engineers like to admit. An AI-built prototype is a good idea when:

• You want something clickable to put in front of customers before spending real money.
• You’re testing which of three ideas people actually want.
• You need a demo for an early investor conversation, and you’ll say it’s a prototype.
• It’s an internal tool with no customer data and nothing to lose.

The rule is simple. Use it to learn, then throw it away. It’s a sketch, not a foundation. The trouble starts when a prototype quietly becomes the product because it looked finished.

What’s the difference between vibe coding and responsible AI?

The tools are often the same. What differs is who’s accountable. We use AI throughout our work at Contic, because it makes good engineers faster. But senior engineers review and own everything that ships.

Used this way, AI is a power tool in skilled hands. Used the other way, it’s a power tool left running on the floor.

What happens if your developer stops replying?

The risk we see most often isn’t dramatic. A developer simply goes quiet. Messages take days to answer, then stop being answered at all.

It happens most with freelancers on a fixed price. They quoted for what they understood. Halfway through, the job turns out harder than they thought. They’re out of their depth, behind on other work and earning nothing for the extra hours. Disappearing feels easier than admitting it.

How to protect yourself

• Own the repository from day one. The code should live in a GitHub account your company controls, not the developer’s. Check that work lands there every few days.
• Own the accounts. Hosting, domains and app store accounts should be in your company’s name, or transferable to it at launch.
• Pay against working software. Tie payments to things you can click, not to time passing.
• Insist on documentation. Ask how a new developer would get up to speed. “Ask me” isn’t an answer.
• Keep the technology common. Every unusual language is another specialist you can’t afford to lose.

That last point is why we prefer one language across the whole product, ideally TypeScript. TypeScript is JavaScript with type checks that catch many mistakes before the code runs. One language means more people can work on every part, and you can hire for it.

“You wouldn’t hire an electrician who wires your house but says… only I’m basically capable of doing it.”

A team doesn’t remove this risk, but it spreads it. If one engineer leaves a studio, the others already know the code.

How much of your time does each option take?

This is the cost nobody puts in a quote.

• With freelancers, you’re the project manager. You write the briefs, chase progress and referee between them. Expect a real part-time job.
• With a studio, you’re the decision maker. You turn up for weekly reviews and judge work, rather than organising it.
• With a fractional CTO, you’re the boss of the boss. They’re part-time, so agree up front how quickly they’ll respond.
• With an AI builder, you’re the whole team. You’re product owner, tester and the person debugging code you didn’t write.

When is each one the right answer?

A freelancer

More often than agencies admit. A freelancer is the right call when:

• You already have a working product and need one feature added.
• Someone technical, like a cofounder or adviser, can review the code.
• The scope is genuinely small and your budget is well under our smallest LaunchPad price of £25k.

Cheap is fine when the work is small and checkable.

An agency or studio

An agency earns its fee when the problem is bigger than one person. That usually means:

• It’s your first product and you don’t have a technical cofounder.
• You need design, build and launch, not just code.
• There’s a fixed date, like an investor demo or a launch event.
• You want a fixed price, so overruns on the agreed scope are the supplier’s problem.

Agencies have their own failure modes. Senior people sell the work and junior people do it. Code and hosting stay in the agency’s accounts after launch, so leaving is painful. Ask who’s actually doing the work before you sign.

A fractional CTO

A fractional CTO makes sense when you’re about to hire engineers, or investors are asking questions you can’t answer. It also helps when others built your product and nobody owns its direction. It doesn’t make sense if what you need is something built. A fractional CTO without a team is advice without hands.

Senior isn’t the same as right for a startup. We’ve seen a VC-backed startup hire a CTO from a big bank. His zero-risk processes meant developers were lucky to merge code once a week. Sales kept promising features the team couldn’t ship, and customers didn’t renew.

What does a good technical partner look like?

A good partner explains the trade-offs in plain English. They push back when you’re about to waste money, and tell you when a feature isn’t worth building.

“A bad technical partner will try and make you feel stupid. Like you’re the problem.”

If you leave every meeting more confused than you arrived, that isn’t your fault. It’s a sign to change partner.

Can you combine them?

Yes, and the best set-ups often do. Validate the idea with a vibe-coded prototype. Then have a studio build the real product on a fixed price. After launch, a fractional CTO can start hiring your team, while the studio keeps the product running until that team is ready.

What doesn’t work is three parties all believing they own the architecture. Name one owner at each stage, in writing.

How do I hire an app developer without getting burned again?

Whichever route you take, ask these before you sign:

• Who exactly will work on this, and are they employees or subcontractors?
• How do you use AI, and who reviews what it writes?
• How often do you put changes live, and how often does a release break something?
• When will the code, hosting and app store accounts move into my company’s name?
• Does the contract assign the IP to my company? Our guide to who owns your code explains why this matters.
• Is the price fixed, and what happens when scope changes? Compare fixed price and time and materials before you choose.
• If you stopped replying tomorrow, what would I have?

A good supplier answers all of these without hesitating. A vague answer to the accounts question is the biggest warning sign. It usually means leaving will be harder than joining.

When shouldn’t you hire an agency like us?

Don’t hire us if you haven’t tested the idea with real customers. A vibe-coded prototype might be exactly the right next step. Don’t hire us for a job a good freelancer can finish in a fortnight. And if your technical cofounder wants to build it, back them.

What does a team-shaped problem look like?

Everyone’s Invited was receiving over 100 submissions a day, and each one needed names, dates and places removed by hand. They also needed a site that survived sudden waves of visitors. We built an AI system that strips identifying details from submissions automatically. We put the site on serverless hosting, which scales up and down with traffic on its own. It has handled over 50,000 submissions and saved 12,500 hours of review.

That project needed AI, infrastructure, design and product people working at the same time. It also needed engineers who understood every line, because the data was as sensitive as data gets. No prompt gets you that.

If a team is the right shape for your product, see what each LaunchPad tier includes and costs. Then talk to us, and we’ll tell you honestly if a freelancer or a prototype would serve you better.