Building a product

The costliest decisions are made in year one.
The bill arrives in year five.

An architecture, a cloud provider, the first three hires: decided in a few weeks, when the company knows less than it ever will, and carried for years. Almost none of these choices can be undone without stopping the product.

Code now arrives faster than it gets read. The decisions inside it, where the data lives, what happens when customers double, who could rebuild it, were made by a model and signed by nobody.

The call comes when a product has to be built and there is nobody yet to build it. That applies to someone founding a company and to a company that has to build something it has never built. The product is designed from scratch; the team is chosen, hired and led until it can walk on its own. The choices that cannot be rewound are taken with someone who has already taken them three times on his own account.

Code
Ten years as a developer
Mondadori, De Agostini, CHIP
Products
Xbinary 2005 · Boole Server 2008
CyberGrant 2022, California
Technical leadership
VALMAX Software
CyberGrant, since 2022
Capital
Formerly managing partner of Tailor Ventures
Co-founder of CyberGrant
Why now

The cost of a technical choice does not show in the quarter it is made. It shows when it is too late to change it.

An agency sells hours. A cloud provider sells its platform. A model produces what it is asked for, with no idea of what will happen in three years. None of them answers for the choice.

Choices that don't rewind

It shows in year five

Changing the architecture or the provider once the product is in production costs more than the product. By then every new feature has been built on top of the wrong choice, and holds it in place.

The choice has to be made well the first time. Not because it cannot be changed, but because by then nobody will be able to afford it.

Generated code

The code is there, the decision isn't

A coding assistant produces in an hour what used to take a week of discussion. The speed is real. The decisions inside that code were made by the model.

What is needed is a written rule on what gets delegated and what gets re-read, and someone who enforces it.

The first hires

Who to hire, and when

The first technical hire decides the next ten. It is almost always made before anyone knows what they are looking for, and it costs as much as an architecture decision.

Who is really needed in year one, who is not, who to hire and who to bring in on a contract: these are decisions to make before the interview, not during it.

The examination to come

Before an investor does it

A fund, a large customer or an acquirer will ask how the product is built and who can carry it forward. Better to build it already the way it will need to be found.

It is the same examination carried out on behalf of funds, seen from the other side of the table. What gets examined →

The method

From the design to a team that walks on its own,
in four moments.

What happens from day one
01

The design. What the product has to do, what data it handles and where that data lives, which architecture still holds in three years, which provider can be left. Put in writing before the first line.

02

The team. Who is really needed in year one and who is not, who to hire and who to bring in on a contract. The written rule on what a coding assistant may be asked and what has to be re-read by a person.

03

The lead. The choices that come up every week, taken with someone who answers for them; generated code re-read before it goes to production; technical debt counted, not accumulated.

04

The handover. The team can carry on by itself. The documentation is what an investor or an acquirer will find when they come to look.

At the table

The questions that come before the start.

They are almost never questions about code.

  • The code we have: can anyone still read it, or was all of it written by a model?
  • If our first developer leaves tomorrow, what stops?
  • Does this architecture hold if customers grow a hundredfold?
  • Does the cloud provider we chose let us leave, or does it keep us?
  • What should we build ourselves and what should we buy?
  • Should the first technical director be hired now, or is it early?
  • What a fund will ask us in due diligence: do we have it?
  • Are we paying down technical debt or piling it up?
Forms of engagement

Three ways of working.

A

Interim technical leadership

From the design to the handover, with a team built for that product. The form for those starting from scratch, or from a prototype that must not become the product by inertia.

  • Architecture and choice of providers
  • Technical hiring and leading the team
  • A written rule on generated code
B

A second opinion before a decision

An architecture, a provider, a key hire, a build-or-buy. One decision, before it is taken. It starts and it ends.

  • A short document
  • The answer even when it is unwelcome
  • No product to place
C

Review of a product already under way

When something has already been built, often in a hurry, and nobody knows how well it holds. Before an investment, a large customer or a change of team.

  • What to keep and what to redo
  • What was generated and never re-read
  • The plan to get through an outside examination

Few engagements are accepted each year, and only one per sector, so as never to sit at the table of two competitors. The condition is set before the start, not after.

Declaration of interests

I am co-founder and technical director of CyberGrant, and the patents in the record are mine. When I lead the technology of a company that is not my own, CyberGrant's technology is not among the options, and the people working on your product do not work on mine. If a conflict emerges during the work, I stop and I tell you.

Valerio Pastore

If you are about to decide how to build your product, or have already decided and have a doubt, the right moment to talk is before the first line. I answer personally.

Get in touch