I came in as CTO with the platform still on a whiteboard. The brief was the whole system: data model, architecture, what gets built in-house and what gets bought.
The decision that mattered most wasn't a technical one in the usual sense. It was the scope call — working out which parts of the vision belonged in version one and which were going to quietly sink it if we tried. Saying no to features in a first build is unpopular in the room and obvious in hindsight.
What I take from it: the hardest part of being the technical authority is being the person willing to cut, and then owning that cut when someone asks six months later why a feature is missing.
Same title, same shape of problem: design the system, then decide who builds it.
I built it myself. Not because delegating is wrong, but because at that size the design and the implementation kept correcting each other — decisions that looked clean in a diagram turned out wrong the moment they hit real code, and I wanted the feedback loop to be one person long.
What I take from it: an architect who never touches the build stops finding out which of their decisions were wrong.
Flushiest
Founder, built & launched My own product. I built it, launched it, and got it covered by four news outlets and radio on a marketing budget that was effectively nothing.
The coverage is the part people ask about. The part that actually taught me something was everything before it — I assumed shipping was the hard bit, and found out that getting a working product in front of people is a completely separate discipline with its own rules, several of which are legal rules I didn't know existed. I ordered a print run of flyers before finding out how constrained handing them out in Amsterdam actually is.
What I take from it: the gap between "it works" and "people know about it" is where most good products die, and almost nobody is warned about it in advance. That gap is what I now advise on.