One queue. Two founders. One request at a time.
The product and engineering team you retain, not the agency you hire per project. Unlimited requests in the queue. One at a time. Pause anytime.
§01 · the problem
Continuous work, no one to give it to.
You need engineering every month, not once. A feature this month, an integration the month after, an AI workflow when the manual version starts eating someone's week. The volume doesn't justify a hire, and a hire takes a recruiting cycle you don't have.
The per-project agency is the other option, and it's built to leave. Scope, ship, invoice, gone — and the context walks out the door at launch, right when the product starts teaching you what it needs next.
§02 · how it works
Four steps, one at a time.
01
Queue it.
Send anything: a feature, a bug, an integration, a landing page, an agent. It goes in the queue. The queue has no cap.
02
One goes active.
We work the top request until it's done, then pull the next. You set the order. One at a time is what keeps each request finished instead of five half-built.
03
See it Friday.
Active work lives on a staging URL and in the Friday demo. You review the product, not a status update.
04
Pause when it's quiet.
Nothing worth queuing this month? Pause. The same two founders pick it back up — nobody new to onboard.
The full week-to-week rhythm is on how we work.
§03 · the queue
What you can put in it.
| Request type | Typical examples |
|---|---|
| Product features | New flows, dashboards, admin tools, the feature the last three sales calls asked for. |
| AI agents & RAG | Retrieval over your documents, agents that finish multi-step work, the evaluation harness around both. |
| Workflow automation | The spreadsheet-and-email process someone on your team runs by hand every week. |
| Integrations | Payments, CRMs, calendars, webhooks, the third-party tool your ops team copies data out of. |
| Design | UI for new features, design-system work, a clickable prototype before a build. |
| Site & commerce | Marketing pages, launch landing pages, Shopify and WooCommerce work. |
| Infrastructure | Deploys, monitoring, performance, the migration nobody wants to own. |
A request too big for one slot — a new product from zero — is a Build. We'll say so before it goes active. Build or retain?
§04 · the won't list
Who it isn't for.
Teams that want an account manager in the middle
The founders are the account managers. Every call, every Loom, every repo. Direct line, or nothing.
Five things moving at once
One active request is the constraint, not a starter plan. If you need parallel tracks this quarter, hire or bring in an agency. Genuinely.
A feature list with no problem behind it
Specs are answers to questions nobody wrote down. Five sentences on the problem before anything goes active.
A post-product-market-fit core product
When the product is the company's only moat, build the in-house team. We'd rather be the bridge to that team than a dependency you resent.
The long version: five things we decline to build.
§05 · price
One monthly price, quoted in 24 hours.
Tell us what's in your queue and we send the number within 24 hours — before any call, before any deck. Ask for pricing
§06 · who you retain
Two founders, four engagements each at most.
Naman Barkiya
Co-founder, engineering lead
Architecture, build, deployment, and the AI infrastructure. Technical questions go to the person who wrote the code.
Abhiraj Sakargaye
Co-founder, growth lead
The first call, scope, positioning, and launch. What the product needs to be worth, and how it reaches the people who pay for it.
Four or fewer active engagements per co-founder, capped on purpose. Past that, the attention tax shows up in the work. More on the team
§07 · proof
What the same two people shipped.
- LaunchProd
Blank repo to a production RAG system with live users in ten weeks, for a Carnegie Mellon-founded startup. Read the postmortem
- SIT Manager
Two agencies stalled for nine and six months. First working version in fourteen days; cut over with thirty minutes of downtime. Read the postmortem
- ONETAPP
Concept to a live cohort in ten weeks, with three features cut in week one. Read the postmortem
Questions founders ask
- What is a retained engineering team?
- A product and engineering team you keep month to month instead of hiring one or buying it per project. With us that means one active request at a time, unlimited requests in the queue, and both founders on the work.
- How does the request queue work?
- You add requests and set the order. We work the top one until it's done and demoed, then pull the next. One active request at a time is the constraint that keeps work finishing.
- What happens when we pause?
- The queue stays where you left it, and the same two founders pick it back up when you restart. There's no new team to onboard.
- Who owns the code?
- You do, from the first commit. The repository lives in your organisation's account.
- Is a retained team better than hiring an engineer?
- It is when the work is continuous but the volume doesn't justify a headcount, or you can't wait out a recruiting cycle. When you need someone inside the company full time for years, hire — we'll tell you on the call.
- How much does a retained team cost?
- One monthly price, quoted per engagement. Send us what's in your queue and we reply with the number within 24 hours.
- How do we start?
- Book a 30-minute call with Naman or Abhiraj, or send a short brief. If it's a fit, the first request goes active with a staging URL on day one.
Keep reading
Talk to the two people who'd do the work.
A 30-minute call with Naman or Abhiraj. Or email two paragraphs on what you're building — we reply with a pricing estimate within 24 hours.
Send two or three times that work, with your timezone. A founder confirms within 24 hours.
Request a call by email