What we build

Version one is a decision about what to leave out

Architecture, build and launch of a first version that goes into production — not a prototype that demos well and stops there.

8–16 weeks from €30,000

This is for you if

  1. You have the product and no technical team The business case is settled. The only way to find out whether it works is to build it, and there is nobody inside the company whose job that is.
  2. You need something real before the next decision A board, a first customer, a partner. A document describing the product does not answer the question they are going to ask.
  3. The last attempt produced something that could not be launched It demonstrated well. Then it turned out there was no way to put it in front of real users without building most of it again.
  4. You know what the product does, not what version one contains The feature list is long, and every item on it has someone who says it is essential. Nobody in the room is the person who gets to say no.
  5. You could build it, but not with the people you have Your engineers are on the systems that earn money today. Taking them off those is the expensive part, and it is expensive in a way that shows up two quarters later.

What we actually build

Accounts and onboarding

Sign-up, identity, and whatever has to be true about someone before they are allowed to use the product at all.

The core action

The one thing the product exists to do — a transaction, an order, a booking, a submission — built first and built properly, because everything else is arranged around it.

The operator console

The screens your own team uses to see what is happening, correct what went wrong, and answer a customer who is on the phone.

Software running on a device

Where the product is not only a website: a screen, a machine, and the service behind it that keeps the two in step.

Money moving through the product

Payments, payouts, balances and the record of each one.

The parts that make it operable

Deployment, monitoring, logs, and a way to release a change without taking the product down. A first version without these is a demonstration.

Work we have delivered in this category

Bitcoin Romania is the clearest example in this category, because two of the things we built for them started from nothing. The ATM software was written from scratch and runs on physical machines: the screen a customer uses to buy or sell, the service behind it, an interface the client's own partners use to load the machines, and the limits Romanian legislation requires applied at the moment of the transaction. The trading platform is the other half — buying and selling, with or without an account.

See all case studies

How a project runs

  1. Deciding what version one is not One to two weeks

    We go through the feature list with you and sort it into three: what the product cannot exist without, what can wait for real users to ask for it, and what turns out not to be needed at all. The third pile is usually the largest and always the hardest to agree on.

    What you get: A written scope listing what is in and, explicitly, what is out — plus a price for the build.

    What we need from you: Whoever can say no. Scoping a first version is a series of decisions to exclude something, and that needs one person with the authority to make them.

  2. Architecture, and the first thing that works end to end Three to four weeks

    We settle the shape of the system, then build the core action all the way through — from what the user does to what gets stored — before anything is decorated.

    What you get: The main path working in a real environment, deployable, with the decisions behind it written down rather than remembered.

    What we need from you: Answers about the rules the product has to follow. They are usually in somebody's head rather than in a document.

  3. The rest of version one The remainder of the project

    The remaining flows, the operator side, and the states nobody thinks about until launch: what a user sees when something fails, and what your team does about it.

    What you get: Version one in production, with the operator console your team will actually use.

    What we need from you: A few people to use it before it is public and tell us what confused them.

  4. Launch, and the decision about version two Ongoing, on a monthly agreement you can end

    We put it in front of users, watch what happens in the first weeks, and hand over the code and the infrastructure — which have been in your accounts since the first phase.

    What you get: The product live, monitoring with a named recipient, and the list of what version one deliberately left out.

    What we need from you: A decision on whether your own team takes it over or we keep running it.

What it costs, and what moves the number

Projects in this category start at €30,000 and run eight to sixteen weeks. That is a first version in production, with the operator side and the parts that keep it running. What moves the number is mostly how much you are willing to leave out.

How much of version one you are willing to leave out
The largest factor, and the only one you control completely. Every item moved out of version one is time you get back, and most of them can be added later — once real users have told you whether they mattered.
Whether money moves through it
A product that holds balances, takes payments or pays out is a different build, and the requirements around it are not negotiable.
Whether there is hardware in the loop
Software running on a machine somebody has to service is not the same as software running in a browser. Updates, failures and what happens while the device is offline all become part of the build.
How many kinds of user
One kind of user is a product. Customers, operators and partners, each seeing something different, is three products sharing a database.
What has to be true on day one
A product that has to be correct from the first transaction costs more than one that can be corrected in week two. Which one you have is a business decision, not a technical one.

Questions we get at this point

How do you decide what goes into version one?

By asking what the product cannot exist without, and treating everything else as a candidate rather than a requirement. You make the calls — we tell you what each one costs in weeks before you make them.

What if we change direction halfway through?

That happens, and it is often the point of building a first version at all. Because the work reaches production in phases, changing direction costs you the phase you are in rather than the project.

What happens when version one works and we need more?

The architecture is settled in the second phase precisely so that version two is an addition rather than a rebuild. You own the code and the infrastructure, so continuing with us stays a choice rather than a dependency.