1Week5KBook the call

What makes an app hard to build?

Never the screens. Screens are a solved problem, which is why a prompt tool can produce them in an afternoon. The hard parts are invisible in every demo and decide everything afterward: what happens when two people act at once, where the money lives, how fast stays fast.

The hard parts are decisions.

Take the simplest booking app. Two people tap the last slot at the same second. Someone must decide: does a hold exist, how long does it live, what releases it, and which of the two requests loses and sees what. That is one decision among dozens, it never appears in a mockup, and getting it wrong sells the same seat twice. Every hard app is a stack of decisions like this, and code is just the residue of having made them.

The pattern behind all of them: single-user software is easy, and concurrency, money and growth are hard. One user clicking through screens can be faked by any tool. Thousands of users colliding over the same rows of data, retrying failed payments, and expecting the feed to load in under a second is where design starts and generation stops.

Where the difficulty actually lives.

Marketplaces. Two sides, money in the middle. The hard parts: payments that split correctly between the platform and the seller, holds and inventory that survive race conditions, refunds and disputes that keep the ledger true, matching that feels fair. The bones of an Uber or a Ticketmaster are these four problems wearing different clothes.

Real time. Chat, presence, live dashboards, collaborative editing. The hard parts: delivering a message exactly once to everyone who should see it, showing who is online without asking the server constantly, and merging two edits made offline to the same sentence. The Google Docs problem is fifty years of computer science wearing a friendly toolbar.

Search and discovery. Crawling, indexing, ranking, freshness. The hard parts: an index that updates without stopping, ranking that mixes relevance with recency and geography, autocomplete under fifty milliseconds. A Yelp is a database with opinions about ordering, and the opinions are the product.

Feeds and scale. The hard parts: whether the feed is computed when someone posts or when someone looks, what happens when one account has a million followers, which caches lie and for how long. Instagram's core loop fits in a week. Its fan-out decisions are the difference between fast and down.

Money. Ledgers, idempotency, reconciliation. The hard parts: a retry that must not charge twice, a balance that is always explainable from its history, cents that never appear or vanish in rounding. Fintech difficulty is bookkeeping rigor enforced by code, and it is unforgiving of vibes.

Why demos hide all of this.

A demo is single-user by definition. One person, one happy path, no retries, no load, no adversary. Every hard property of a real system is invisible under those conditions, which is why a generated app and an engineered app look identical on launch day and behave differently in week three. The difference was never on the screen. It was in the decisions nobody watching the demo could see.

This is also the honest boundary of the AI platforms, and of AI itself. The models write excellent code within a decided structure. They do not decide whether the hold is atomic, and software that grows by prompt inherits whatever nobody decided. Our whole trade is making those calls first and letting the machine do the typing, which is the subject of the Lovable comparison and the reason a genuinely hard core now fits in a week and $5,000.

Questions.

How do I know if my app idea is a hard build?

Four tests. Will strangers trust it with money? Can two users acting at the same time create a conflict the software must resolve? Does it have to stay fast as data grows? Does anything happen live, like chat, presence or collaborative editing? One yes puts you in hard-build territory. Zero yeses means your app is screens over a database, and you can build it cheaply on a platform.

Why do vibe-coding platforms stall on these apps?

Because the hard parts are decisions, and prompt tools do not make decisions. They generate something that looks like a marketplace or a chat app, and the missing tenth is exactly the part that made the app hard: the hold that releases correctly, the message that arrives exactly once, the balance that survives a retry. Looking right and being right diverge precisely where the app gets interesting.

Does hard mean expensive?

It used to. Agencies price these builds at $25,000 to $150,000 because they price by team-months, and the thinking used to be inseparable from months of typing. The typing collapsed. The thinking is now the whole job, two senior engineers do it AI-first in a week, and that is the entire reason our price is $5,000.

Can the hard core really fit in one week?

The core can, and the word core is doing honest work in that sentence. One week ships a booking system that cannot double-sell, not all of Ticketmaster. We put the line in writing before you pay: what the week includes, and what a mature product would still need. Anyone who will not name that line for you is selling.

What should I bring to a scoping call?

The one flow your product cannot exist without, described in a paragraph. Who acts, what they see, what must never go wrong. From that single flow a senior engineer can usually name every hard decision in your build within the first ten minutes, and that conversation is what the free call is for.

Related: from prototype to production, the stack for an MVP, and all articles.

Tell us what you want built.

A free 20 minute call. Describe your one essential flow and we will name the hard decisions in it, whether or not you build with us.

Or see how the week works.