Capital is spent on decisions, not on keystrokes.
Most software money is lost before anyone writes bad code. It goes on building the wrong thing carefully, discovering it late, and rebuilding under time pressure. Our sequence exists to make that discovery happen on paper, in week one, where it costs days.
The four stops, in detail.
Specify the product
We interrogate the idea until the parameters hold still: who it is for, what it must do, what it must never do, and which dependencies decide the timeline. Nothing is built yet.
A written specification, a dependency map and a sequenced estimate.
Build the proof
We build the parts most likely to be wrong (the API structures, the core workflow, the mechanic the whole thing rests on) at high fidelity and nothing else.
A running prototype and an estimate revised by what it proved.
Build the MVP
The core product, in production, in front of early adopters. Deployment, observability, backups and access control are part of the first release, not a later project.
A deployed product, real usage data, and every account in your name.
Scale to MLP
Usage tells us which details matter. We refine them, harden what is now load-bearing, and keep going until the product is one people choose rather than tolerate.
A product your team can run, or that we keep running for you.
How engagements are shaped.
Three shapes cover almost everything founders ask for. We will tell you on the call which one fits, including when the honest answer is none of them.
- Specification sprint
- One to two weeks, fixed scope, fixed fee. You leave with the specification, the dependency map and a sequenced estimate, yours to build with anyone, including an in-house team or another studio.The most common way founders start with us, and the cheapest way to find out whether we are right for you.
- Build engagement
- Proof of concept through MVP to MLP, run as a continuous engagement against the signed specification. Scope changes are re-estimated in the open rather than absorbed quietly and paid for in the deadline.Founder-led, with senior engineers brought in when the work calls for it.
- Technical direction
- Fractional CTO work for teams that have engineers but no one setting direction: architecture decisions, hiring input, code and vendor review, and the technical due diligence that gets done to you when you raise.Usually a fixed number of days per month.
On pricing
We price an engagement after the scoping call, against a written scope, and we do not quote before we understand what is being asked. Rates are day-rate based, invoiced monthly from an EU-registered company, with reverse-charge VAT for EU business clients. We take no equity, and we do not ask for it later.
What we will talk you out of.
Building before the specification holds
If the parameters are still moving, more code makes the problem more expensive, not clearer.
A bespoke platform where a stack exists
We maintain the Payload App Stack in the open precisely so your budget goes to the part only you can build.
Scaling infrastructure for load you do not have
Boring infrastructure, sized for the traffic that exists, moved when the traffic arrives.
Hiring a team to start a product
A team is the right answer once the product is proven. Before that it is a payroll with an unresolved specification attached.
“Layron moves a deal from sourcing to shareable brief in one single session. What took us hours before is now a matter of minutes.”
That result did not come from a clever sprint. It came from deciding, on paper and early, that the product’s job was to end at a shareable brief, and then refusing to build anything that did not serve that ending.
Start with the specification.
One call, 45 minutes. If a specification sprint is the right first step, we will scope it on the call. If it is not, we will say what is.
or write to hello@genica.org