Ship a narrow product that can learn, then automate and acquire on purpose
A startup’s first software problem is not “scale.” It is a crisp object model, a first workflow that a real user can complete, instrumentation, and the discipline to leave the rest unbuilt. We work with founders on that first version, on the automations that remove founder copy-paste, and on an acquisition path that does not outrun signup. We do not promise fundraising, product-market fit, or a user number. We will push back on a v1 that is secretly three products.
MVP means something specific here
Minimum viable is not “ugly on purpose.” It is the smallest product that tests a business hypothesis: a buyer will complete this job, or a user will return for this reason. That requires a real backend, real auth if you have accounts, and analytics events you named in advance. A clickable prototype can precede this; it is not a substitute if you intend to charge or to hold data.
Architecture for a startup should be boring and owned: a Laravel or similar API, React, a single PostgreSQL, deploys you can run. Premature microservices, multi-region, and a marketplace in v1 are how runways disappear. Tenancy can be honest from day one if you will have more than one customer, a shared table with a tenant key is enough for many first versions; a full isolation theatre is not.
Acquisition is a second system. Paid traffic into a waitlist can be valid. Paid traffic into a broken onboarding is waste. We would rather instrument the product and fix activation than scale ads into a leak. When growth is in scope, it is the same spine as our growth work: offer, page, event, CRM, follow-up.
Problems early teams actually have
- The deck is the spec
Twelve personas, no first job. Discovery has to pick one.
- No-code hit a permission wall
It demos. It cannot tenant, bill, or pass a basic security conversation. Time to a real app.
- Founder is the integration
Every signup is a manual Stripe and a spreadsheet. First automation is allowed, after the object exists.
- Building for a press launch
Features for a screenshot. Users cannot complete the job. Cut the screenshot features.
- Ads before activation
CAC conversations with no onboarding event. Fix the product path first.
- Contractor soup
No repo ownership, no staging. You need accounts in your name and a handover, even at five people.
What we typically do with startups
- MVP product engineering
One workflow, auth, admin, deploy, events.
- SaaS-shaped v1
Tenancy and entitlements only as thick as the first buyers require.
- UI for the first job
Empty states and onboarding, not a brand universe.
- Early automation
Provisioning, mail, CRM note, kill the copy-paste.
- First growth spine
A page, tracking, a CRM. Channel tests after the event fires.
- Mobile only if the job is mobile
Web first is the default. Stores later.
Use cases
- B2B workflow product
Replace a sheet for a specific operator. Vertical first.
- Marketplace temptation
We will argue for one side of the market in v1. Two-sided liquidity is not an MVP.
- AI-featured product
A model on one job with logging and a fallback. Not “an agent that runs the company.”
- Services firm productizing
A client login for a delivery you already do. Honesty about what is still a service.
How a startup engagement runs
- Hypothesis and cut list
What we are trying to learn. What is explicitly out. If this is fuzzy, we stop and write it.
- Thin architecture
Stack you can hire for. Secrets in your cloud. Analytics property in your org.
- Build the job
Slices a founder can click weekly. No silent second product.
- Instrument
Sign-up, activation, the failure you care about. Then decide on ads.
- Iterate or stop
Evidence from users, not from a new feature idea. We will not “just add the marketplace.”
Questions we hear first
- Can you build this for equity only?
- Not as a default offer on this site. Commercial terms are a contract. We do not list a studio brand or fake portfolio companies.
- How fast is an MVP?
- It depends on the job and whether you already have designs, APIs and a decision-maker. Anyone quoting a date before a cut list is guessing. Discovery produces a range for a named scope.
- Will you also be our CMO / CTO?
- We deliver scoped work. Fractional titles can be discussed; they are not implied by an MVP statement of work.
- Should we start on Bubble / Glide?
- For a throwaway demand test, maybe. For tenancy, money, or unique data, you will pay twice. We will say which side you are on.
- Do you help with pitch decks?
- We can make the product real enough to screenshot honestly. We do not write fundraising narrative as a standard service.
Related
Send the hypothesis and the cut list
One buyer, one job, what you refuse to build in v1, and whether anyone has completed the job even manually. We will tell you if this is an MVP, a prototype, or still a slide.