Product
Ship the first version, then keep shipping
Most software gets sold as a project: a scope, a deliverable, a handoff. Products do not behave that way. They get shaped, shipped small, and then corrected by what users do with them. We run that loop alongside your team instead of handing you a finished thing and leaving.
The loop
How a product engagement actually runs
- Shape before you build
Discovery is where we decide what not to build. We map the workflow, name the one job the first version has to do, and cut everything else into the backlog. Most of the value in this phase is the scope we talk you out of.
- Ship a version that runs
The first release runs in production with real data and the people who will use it. Scope stays small on purpose: one workflow, end to end. A ship date is a design constraint, so picking a stack that respects it is part of the work rather than a compromise made later.
- Keep shipping after the launch
Version one is where the roadmap starts. PQ ESSA was already a working application when we came in, and the round we delivered was a Nuxt to Next.js migration, a redesigned authentication flow with SSO for some users, and dashboard views relaid out for usability.
Product work
Products we shaped, shipped, and kept shipping
Inside a build
The decisions that separate a product from a deliverable.
- 01Design and engineering in one group
Design and engineering sit in the same working group from day one. The entire Brightfold platform was designed in Figma, with component libraries establishing a scalable system, and Dev Mode carried specifications and measurements across the handoff. Components get built the way they were drawn.
- 02A content model your team can operate
Someone other than an engineer has to be able to change the words. We model content as reusable blocks with types behind them. CrewAI's marketing team assembles pages from those blocks in Contentful and moves independently, while engineering keeps the rules for layout, analytics, and search.
- 03Real time where it earns its cost
Live state earns its cost or it does not go in. Subcore's dashboard pushes new agent events and generated summaries to every connected client through Supabase Realtime, so operators see what is happening now rather than after a refresh. A layered provider architecture keeps those concerns separate.
- 04People in the path when software should not decide
Escalation is a feature, not a fallback, and it costs real engineering. Getting a person into a live agent conversation on Subcore meant configuring each agent's backend, testing that connection, building endpoints to claim a session and hand it back, and rendering both speakers in one thread.
- 05We change the architecture when it is wrong
On Google's cloud IDE we tried a VS Code extension with Yjs and it would not hold, because Yjs needs synchronous access to the document model and the extension API is asynchronous. That failed work is what let us recommend forking VS Code instead.
- 06Cost and scale get profiled, not assumed
Every connection to a workspace spun up a full set of backend processes. Standard 8 GB VMs ran out of memory with a handful of users, and only 64 GB machines held about ten, which was far too expensive. We sat with Google's infrastructure team, profiled it, and brought the per-connection footprint down.
Honest scoping
Not every engagement should be a product engagement
- Buy a project when the end state is known
If you can write down what done looks like and it will not change while you build, a scoped project is cheaper and faster. Migrations, a redesign of a settled product, and integrations against a fixed contract all fit that shape. Do not pay for a roadmap you already have.
- Product engagements need a decider
The loop only works when one person on your side can change their mind about scope in a week and make it stick. Without that person, iteration turns into a committee and you end up paying product prices for project economics. That is the worst of both.
- Most product work continues on a retainer
A live roadmap usually means a monthly retainer, and that is the shape most product work takes once the first version ships. It is worth deciding deliberately rather than by default, because the answer changes how the engagement is scoped and what your own team needs to be ready for.
Related Services
Show us the workflow, not the feature list.
Version one comes out of that.
Walk us through the job the product is supposed to do and who does it today. We will come back with what version one covers, what it deliberately leaves out, and what the two releases after it look like once people are using it.
Work with us