An application your teams actually use,
not a project that never ends.

We write with you the question your product has to settle. We cut everything that does not answer it. We design the journeys, we build it properly, we put it into the hands of real users. We watch what they do, not what they say. Then we hand it all over.

What you get: A product online in four months, used by real people with real data, and an answer to the question that matters: does this deserve to go further.

What you do not have to do: Write a specification, choose the platform, hire before validating, or commit a development budget on a hunch.

A first version is not a cut-price version of the finished product. It is the tool that tells you whether the finished product deserves to exist.

We build it properly, on Bubble or FlutterFlow depending on whether your product lives in a browser or in the app stores. In four months you have an application real users can use, with real data, and the indicators to decide what comes next.

What we do not do: generate an impressive prototype that will not last three months. What we deliver has a considered data model, managed permissions, and can evolve without being rebuilt.

The practical consequence is that a first version is judged on what it teaches you, not on what it contains. An application that does everything you imagined and that nobody uses has cost four months and demonstrated nothing. An application that does one thing, used three times a week by ten people, has already settled the question that mattered.

The choice of tool is calculated rather than argued. We have set that decision out in our comparisons, in particular Bolt or Lovable for AI-assisted generators, and Framer or Webflow when the need is in fact a website and not an application.

Most projects that fail do not fail in the build. They fail because nobody wrote down, before starting, what the product had to demonstrate. You then build a reduced version of everything, instead of a complete version of the one thing that counts.

The question to write before the first mockup

A first version answers one question and one only. It is always phrased the same way: “will people like X do Y often enough for Z to become viable?” Until that sentence is written with real names, a real behaviour and a real threshold, there is no project, there is a hunch.

We devote the first stage to that, and it is almost always the most uncomfortable part of the framing. It forces you to admit that some features you are attached to do not serve the demonstration, and will therefore wait.

Three things a first version really demonstrates

• That the problem exists strongly enough for somebody to change their current habit. That is the hardest point, and the most often overlooked: your competitor is not another piece of software, it is the spreadsheet that already works.
• That the journey stands up without you. If a user needs a demonstration to understand, the product is not ready, whatever its satisfaction score in a meeting.
• That use repeats. A product tried once by a hundred people is worth less than a product used every week by ten.

Three things it will not demonstrate

It will say nothing about your ability to handle load, since there will be no load. It will say nothing about your cost of acquisition at scale, since the first users almost always come from your own network. And it will not validate a price model: agreeing to pay and agreeing to pay that price are two separate questions, and the second is tested later, on a larger volume.

We say so during framing rather than at delivery, because that is when the knowledge changes a decision. A first version presented to investors as proof of scalability turns against whoever presents it.

The written scope, and what it prevents

At the end of the framing you have a list of what will be built and, above all, a list of what will not. The second is the one that protects the project. Without it, every week brings a new idea, each reasonable on its own, and the product drifts until the budget runs out before launch.

That list is not a permanent refusal. It is dated: what does not go into the first version goes into the next batch, and that next batch is decided with the data from the first, not with the assumptions you started with.

The question always comes too early. It is settled in ten minutes once the scope is written, and takes weeks when asked beforehand.

The criterion that really decides

Does your product live in a browser or on a phone? That is not a matter of taste but of real use. A tool handled sitting in front of a screen, with tables, filters and long data entry, lives in a browser. A tool taken out of a pocket on a building site, in a corridor or in a lorry, with photographs, location and notifications, lives on a phone.

Many projects want both. At the first-version stage, wanting both is almost always the best way to miss both: the budget splits, and each version arrives half finished. We ask you to choose, knowing that the second platform is not condemned, it is postponed.

What each family of tools makes easy

• The browser makes easy: linked data, permissions by role, filtered views and export. It is the ground of internal business tools and marketplaces.
• Native mobile makes easy: the camera, location, working offline and notifications. It is the ground of field applications and repeated consumer use.

AI-assisted generators, and their real place

They produce a credible interface in a few hours, and that is a genuine gain for showing a direction. Their limit appears as soon as what was generated has to evolve: the data model is often implicit, the logic scattered, and taking it over costs more than the initial build saved.

So we use them where they are good, which is exploring quickly before building, and rarely as the foundation of what will remain. We set out what each can do in our comparison Bolt or Lovable.

What “properly built” means to us

Our approach has no intrinsic virtue: it makes building well as easy as building badly, simply faster in both cases. What separates a product that will last from a product that will have to be rebuilt comes down to three things, and none of them is visible on screen.

A data model thought through before the first page, because that is what cannot be corrected without starting again. Permissions managed at the level of the data and not of the display, because a hidden button is not protection. And a naming convention held to, so that whoever takes the product over in a year understands what they are looking at.

Our approach has a ceiling. Passing over it in silence would be convenient at the point of sale and expensive in use, so we set it out during framing.

The four signals that announce the ceiling

• Display times degrade on the screens handling many rows, and optimisation is no longer enough.
• A compliance requirement demands control over hosting or encryption that the platform does not allow.
• The cost of the platform, indexed to usage, becomes comparable to the cost of a technical team.
• The business logic becomes specific enough that you spend more time working around the tool than using it.

None of these signals arrives during a first version. They arrive with success, which is good news: the ceiling of our development foundations is a growth problem, not a starting problem.

Migration, when it comes up

A product does not convert automatically into a custom-developed product. What does transfer, however, is what costs the most to produce: the validated data model, the journeys proven by real users, the written business rules, and the knowledge of what serves no purpose. A technical team starting with that does not build the same thing as a team starting with a specification.

That is where the first version takes its real economic value: it does not replace development, it sharply reduces its risk. Rebuilding a product whose use is known is a framed project; building a product whose use is assumed is a bet.

How we limit dependency from the start

The data must be exportable in a readable format, and we check that at the beginning of the project and not on the day the question arises. The business logic is documented in plain language, outside the tool, so that it survives the platform. And the connections with your other software go through standard mechanisms, which makes them reproducible elsewhere. When those connections become numerous, they belong to process automation more than to the product itself.

A first version is not a project you hand over. It is a project run by two, and the load on the client side is the variable nobody announces at signature. We would rather write it down.

What we expect from you, concretely

• One person who decides, available one to two hours a week, with the mandate to settle a question without referring it elsewhere. It is the single most decisive condition for meeting the deadline.
• Access to real users, or failing that to people who genuinely resemble them. Without them, the product is validated between us, which validates nothing.
• Knowledge of the trade, which we do not have and will never have as well as you. The implicit rules, the exceptions, the special cases written down nowhere.
• Real content where it exists: a product filled with dummy text tests badly, because users react to substance as much as to form.

What we carry

Designing the journeys, the build, the data model, the permissions, the launch, and preparing the test sessions. We also carry the most thankless function in the project, which consists of defending the written scope: reminding everyone, each time a new idea appears, that it may well be good but that it is not in the current batch.

The rhythm, and why it is short

We work in fortnightly cycles, with something you can handle at the end of each. That is not a methodological preference, it is a protection: a project that shows nothing for two months has no way of knowing it is drifting, and discovers the gap at the point where it costs most to correct.

The corollary is that you will see imperfect versions early. A first version that does not look finished is not an alarm signal, it is normal. The alarm signal would be the opposite.

What makes projects slip, in our experience

Three causes recur, and none is technical. A decision waiting for a meeting that is never scheduled. A scope reopened without the deadline being reopened with it. And test users you never manage to mobilise, so that the product is judged on internal opinions. We flag all three the moment they appear, rather than absorbing them in silence until delivery.

Comparing two first-version quotes means nothing until you know what each includes. Here is our breakdown, so the comparison is possible.

What is always included

• The framing, meaning writing the question to demonstrate and the scope that goes with it.
• Designing the journeys and the screens, which is the real work.
• The build, the data model and permission management.
• The launch, then handover to your team and the documentation that goes with it.

What is costed separately, and why

Platform subscriptions, because they are in your name and depend on your usage volume. Acquiring the first users, because that is a separate trade and often the real critical path. Connections to your management tools, because a CRM integration is a project in itself and not a tick box.

We take them out of the package deliberately. Including them would allow a rounder price, at the cost of a decision you would never see being made.

The next batch, which is not a rent

After launch, what comes next is decided on usage data, not on the wish list you started with. We prefer a short batch, priced on a written scope, to a monthly retainer that installs a dependency without committing to a result.