How we decide
Before scope becomes code, we ask what needs to exist, what breaks later, and what should wait. The answers get written down: what we chose, what we cut, and why.
The questions
We ask them while they're still cheap to answer.
The order matters: we define what a product needs to be before we worry about how it's built. Then we dream about what it can grow into.
№ 1
Not what could exist… what has to exist. We start from the workflow the product must carry and the person it must carry it for. Then strip the scope to something that answers the actual need. Most feature lists shrink under this question. That's the point of asking it first.
№ 2
Architecture risk, integration risk, the expensive unknowns. Auth, money, permissions, hardware that goes offline, the recovery path for the failure you know is coming. The concrete reality a demo never touches and a production system can't avoid. Finding these in a conversation costs an afternoon. Finding them in month four costs real money.
№ 3
Some of the best decisions in the work below were about sequence: what launch actually needs, what can follow it, and what should stay out entirely. A thing that waits is written down with its reason so it comes back on evidence, not on momentum.
Four calls from live work
The option that lost, and why
PebbleSpaces
Stabilize the prototype we had. Rebuild it after launch.
We knew the inherited codebase needed a rewrite, but the first location was six weeks away. So we spent that time fixing the booking, payment, and door access people would use on day one. The full rebuild waited until real bookings showed us which problems were worth solving.
Cut: the full rewrite
Case studyThe CyberNest
The scraper stayed. We built the work history it couldn't.
CyberNest used third-party scrapers to give new experts a head start, but the work history arrived with gaps. We kept the import and built a first-in-class custom work history feature so experts could add what it missed.
Cut: the scraper as the full work history
Case studyShakey Graves
Every song already existed. The movie didn't.
Every soundtrack used recordings Shakey had already made, artwork from his own library, and prompts we wrote with him. The generator could arrange that material. It could not invent new songs.
Hyperlocology
We used the month to build the editor too.
Hard-coded templates would have turned every new customer story and job listing into a development request. We used the month to build the editor too, so Hyperlocology's team could make the next page themselves.
Cut: hard-coded page templates
Case studyEvery case study documents its decisions the same way.
The record
If you can't audit the judgment, you're taking our word for it. Every engagement produces a written record of the decisions that shaped it, written at the time, with the reasoning attached.
A running ledger of the decisions made on a project. Entries get written as discussions happen. The point is that the whole team stays aligned on what the product is, and when that definition changes, we know.
A Product Inception ends in a memo, not a deck: the decisions, the assumptions, the risks, and the non-goals in plain language, with a recommended path: build, change direction, or stop cleanly. It's the record that makes the prototype still mean something six months later.
Scope a Product InceptionBuilds are phased, and each phase ends at a decision point: stop, redirect, or continue, on evidence. The record is what keeps those points honest. You're deciding against what was written down, not against anyone's recollection.
How engagements are pricedBring us the decision you're stuck on. That's where every engagement starts.
Bring us the decisionFreeThirty minutesReply within one business dayhello@houseofgiants.com