Insights · 2026-10-20 · 3 min read

Why every project starts with a two-week prototype

Nobody should sign a large contract on a slide deck. Here is what the first two weeks are for and what they are not.

The problem with proposals

A proposal is a promise written before anyone has touched the hard part. The hard part is where projects fail: the integration that doesn't have the API it was supposed to have, the scene that doesn't hold frame rate on the phones customers own, the model that is almost right. A proposal can't know this. A prototype can.

What the two weeks are for

One working slice, through the hard part, that you can open. For a configurator, one product with every option at full speed on the cheapest phone you care about. For an agent, your real facts, one channel, one task. For a platform, the one feature the whole thing depends on, running on your real data. Rough edges everywhere else, on purpose.

What they are not for

Not a design exercise. Not a document. Not a demo built to impress and thrown away: the prototype's code is the first stage of the build, in your repository, and if you stop you keep it.

Why a flat price

So the decision is cheap to make and cheap to walk away from. The price is agreed on the first call and shown in your currency. If we miss the written date you don't pay for it. After the two weeks you have something running, a build plan with stages and dates, and the choice.

When we skip it

A launch page or a company website doesn't need one; the price is fixed and the work is known. Everything with an unknown in it does.

Tell us what you need built.

An engineer reads it and replies within minutes, in your language. Every project starts with a two-week prototype at a flat price.

Why every project starts with a two-week prototype — eORB