Two-sided marketplaces have a scoping problem that other MVPs don’t: you’re building for two kinds of user at once, plus yourself as the operator. The natural spec is four apps. Customer, supplier, admin, website.

I’ve built all four for a real marketplace. As head of technology at Urban Culture, an at-home salon marketplace, I worked on a customer app, a partner app, an admin console and a web app, and we grew to 500K registered users across six cities. They all earned their place. My point is about order.

The test: is it on the transaction loop?

A marketplace MVP needs one loop to work end to end. A buyer finds something, pays, a supplier delivers, the supplier is paid, and you can see and fix every step. If a feature isn’t on that loop, it’s a candidate for faking or cutting.

Keep

• A curated catalog or service menu. No supplier self-listing yet.
• Checkout with payment upfront.
• Supplier payouts, batched weekly. Stripe Connect in the US charges $2 per active account a month plus 0.25% + 25¢ per payout.
• Status updates by SMS or email.
• An admin view with an audit log of every manual action.

Fake

• Matching or dispatch: you assign by hand, and the log becomes your data.
• Vetting: an interview, a trial job and a checkbox.
• Support: your phone number.
• Reviews: one private rating per job.

There are standard names for this. Doing the work by hand is a concierge MVP. Doing it by hand behind an automated-looking front is a Wizard of Oz MVP. Both are respectable, and both teach you the real workflow before you pay to code it.

Cut

In-app chat, wallets, referrals, coupons, search and filters, recommendations, a separate web app. A short curated list doesn’t need search. A landing page can link to the app.

Which side gets the real app?

Usually supply. In Lenny Rachitsky’s interviews with 17 successful marketplaces, 14 focused almost all early resources on supply. Three questions decide it: who uses the product daily, who has more alternatives, and where the hard part of the workflow lives. A partner doing five jobs a day needs an app. A customer booking monthly can use a web page.

What you can’t cut

The money flow, written down. A list of states and who can move between them. An audit trail for disputes. And ownership: your company should own the repository, payment account and cloud accounts from day one.

Can no-code do it?

For a standard listings-and-booking marketplace, yes. Sharetribe costs $39 a month to build and $199 a month live on yearly billing. It gets harder when your workflow is unusual: travel-dependent time slots, multi-vendor baskets, custom payout rules.

When to build the next app

When manual work on that side is a bottleneck you can measure: you spend an hour a day messaging them, the assignment log shows a pattern, or a cost line has grown enough that removing it pays for the build. That’s the rule that made our geolocation service (−80% maps cost) and coupon engine (+16% average cart) worth building at Urban Culture.

With this scope and one senior engineer, my rough estimate for a marketplace MVP is $15K–$28K over 6–10 weeks.

Full breakdown with the keep / fake / cut table: https://akashbansal.tech/blog/marketplace-mvp-what-to-cut/?utm_source=medium&utm_medium=referral&utm_campaign=marketplace-mvp-what-to-cut

Akash Bansal, founding engineer: I build MVPs and AI products end-to-end for founders.

Written with AI assistance from my own notes and project experience. The full article, with sources, is linked above.

When you read the replies, the advice is rarely “you picked a crook.” It’s structural: tie payments to milestones, write the requirements down, own your code. The deal set up the failure before anyone wrote a line.

I’m a founding engineer who builds MVPs, so I have an interest here. But the useful part is the mechanism, and it applies whoever you hire.

A contract is a protocol

Think of a development contract the way an engineer thinks about a protocol between two parties with different incentives. A good protocol doesn’t depend on anyone being nice. It makes the expensive failure states hard to reach. Most burned founders signed a protocol with seven open holes.

Hole 1: money before work. Paying upfront removes your only leverage. A discount for paying everything upfront is a discount for giving that leverage away. Pay per milestone, released after you’ve clicked through a working demo.

Hole 2: scope as a vibe. If the scope lives in calls and a pitch deck, every misunderstanding becomes a change request. Write down what’s in version one, what’s out, and how changes are priced. Then get a fixed quote.

Hole 3: hourly incentives. As Brad Luttrell put it in his piece on outsourced development, “Agencies bill for hours, not years.” On hourly terms, nobody on the vendor side is paid to say “cut this.” A fixed price flips that.

Hole 4: being the small account. Luttrell again: “You will never be a priority.” Senior people sell and juniors build. Put the named engineer in the contract.

Hole 5: their accounts, your product. If the repository, hosting or app store account belongs to them, you’re renting your own product. Create the accounts yourself from day one, and get IP assigned to your company.

Hole 6: no visibility. “80% done” can’t be checked. A demo you can click every week can.

Hole 7: no exit. Software needs upkeep. Without docs, a readme and a handover, you’re tied to one team forever.

What good terms can’t do

They won’t stop you building the wrong product, and they won’t stop you changing your mind every week. Fixed scope also costs you flexibility: changes get priced. And plenty of agencies do good work. Commenters in those same threads said so. The question isn’t agency versus freelancer. It’s whether the structure protects you.

If you’ve already been burned

Get admin access to everything and export your data first. Pay an independent senior engineer for a few hours to judge whether the code is worth keeping. Read your contract. Then rescope smaller before you rebuild.

Full breakdown with the cause-and-fix table and sources: https://akashbansal.tech/blog/why-founders-waste-50k-on-agencies/?utm_source=medium&utm_medium=referral&utm_campaign=why-founders-waste-50k-on-agencies

(~760 words)

Akash Bansal, founding engineer: I build MVPs and AI products end-to-end for founders.

Written with AI assistance from my own notes and project experience. The full article, with sources, is linked above.

The difference is the database

Everything else (auth, storage, functions, realtime) is close enough that it rarely decides. Firestore is documents and collections, read straight from the client, guarded by security rules. Supabase is Postgres: tables, foreign keys, SQL, guarded by row-level security.

Pricing, checked November 2026

• Free: Firebase: Spark: 1 GiB, 50K reads / 20K writes / 20K deletes per day; no Functions or Storage; Supabase: 500 MB DB, 1 GB files, 50K MAU, 2 projects; pauses after 7 idle days
• Paid: Firebase: Blaze: $0.03 / 100K reads, $0.09 / 100K writes (Firestore Standard, default location); Supabase: Pro: $25/mo incl. $10 compute (Micro), 8 GB DB, 100K MAU, 250 GB egress
• Spend limit: Firebase: Budget alerts don’t pause services; Supabase: Spend cap on usage items; compute excluded

Sources: Firebase pricing, Firestore pricing, Supabase pricing, Supabase compute, Supabase cost control.

Firestore cost is a code-review topic

Every document a query returns is a billable read. Illustrative maths: 10K DAU × 50 docs × 5 opens/day = 2.5M reads/day ≈ 75M/month. After the free quota, that’s about $22/month. A listener on a 500-doc collection that re-reads after every reconnect multiplies it by ten.

Two rules straight from the Firestore best-practices page:

1. Never use offsets. Skipped documents are still retrieved and billed. Use cursors. On Aviate (Gmail → résumé scoring, unattended) I paged with cursors plus a bounded concurrency pool so background jobs stay within quota.
2. Ramp new collections with 500/50/5. Start at 500 ops/sec and add 50% every 5 minutes.

Supabase cost is a sizing topic

Free runs on Nano (shared CPU, ≤0.5 GB RAM, 60 connections). Pro’s credit covers Micro (1 GB). Small ~$15, Medium ~$60, Large ~$110 a month. A slow query won’t bill per row; it’ll push you up a size.

Data model: per-user reads vs cross-user joins

If screens mostly read one user’s things, Firestore is fast and simple. If screens join across users (teams, roles, invoices, “unpaid invoices for customers in Pune”), Postgres is one query and Firestore is denormalised copies kept in sync by functions. A marketplace sits in between: Firestore for the apps, plus the official Firestore → BigQuery extension for reporting, is a shape that works.

Security: same failure, different syntax

RLS off or using (true) on Supabase; test-mode or "signed in but not owner" rules on Firebase. Policies in SQL are easier to review in migrations; App Check is a real Firebase advantage against non-app clients.

Other options

• Firebase SQL Connect (previously Data Connect): managed Cloud SQL Postgres, 3-month trial, then from about $9.37/month per Firebase’s pricing page. Spark projects not upgraded by the end of the trial get archived.
• Plain managed Postgres (e.g. Neon, which scales to zero) behind your own API.

My rule of thumb

Three entities linked many-to-many on day one: Postgres. Mobile-first, per-user, offline: Firebase, with BigQuery when reports arrive. Migrating later is a data model migration, so the first choice matters more than the bill.

The full article, with tables and sources: https://akashbansal.tech/blog/firebase-vs-supabase-2026/?utm_source=medium&utm_medium=referral&utm_campaign=firebase-vs-supabase-2026

Akash Bansal, founding engineer: I build MVPs and AI products end-to-end for founders.

Written with AI assistance from my own notes and project experience. The full article, with sources, is linked above.

When a vibe-coded app “hits a wall”, founders usually feel it as friction. Every prompt that fixes one screen breaks another. The AI rewrites the same file over and over. Nobody is sure why login sometimes fails. Those are structure problems, and they’re fixable.

The problems that should worry you are the ones you can’t see in the UI.

1. Row-level security. If the browser talks directly to a Supabase or Postgres backend, RLS is the only thing stopping a visitor from reading every row. Supabase’s docs say RLS should always be enabled on tables in an exposed schema, and tables created with raw SQL don’t get it by default. In 2025, Matt Palmer scanned 1,645 Lovable-showcase apps and found 170 with 303 endpoints exposed by inadequate RLS (CVE-2025-48757). On one app, a visitor could insert records marked as paid. Query pg_tables for public tables where rowsecurity = false, then check that each policy limits rows to their owner. using (true) doesn't.

2. Keys in the browser. Search your live bundle for service_role, sk_ and secret. GitGuardian counted 28.65 million new secrets leaked in public GitHub commits in 2025, with AI-service secrets up 81% year on year. If a key was ever public, rotate it.

3. Authorization on the server. Broken access control is number one on the OWASP Top 10 for 2025. The classic vibe-coded version: the UI hides the admin button, but the API route only checks that you’re logged in. Test with two accounts. Platforms have gaps too: Wiz found an authentication bypass in Base44 that let outsiders register on private apps using a public app ID. It was fixed within 24 hours.

4. Payments confirmed by verified webhooks, never by the browser.

5. Input treated as untrusted. Veracode’s vendor research found AI-generated code introduced security flaws in about 45% of tasks, and failed to defend against cross-site scripting 86% of the time.

6. A backup you’ve actually restored.

7. Every account in your name: repo, database, hosting, domain, billing.

Then make the call. Keep prompting if there’s no real user data yet and changes are still easy. A prototype that tests demand is doing its job. Rescue if the core works and the data model fits the business, but security, tests and deployment don’t. Rebuild only when the data model is wrong: you sell to teams but the database only knows individuals, or bookings and payments share no ID. A rebuild isn’t starting from zero. Your vibe-coded app is the best spec you’ll ever have.

What survives a rebuild. Your screens, flows, copy and real user feedback all carry over. What gets rebuilt is the backend and the data model, followed by a migration of existing users.

While you’re still prompting, two habits make it safer: commit to Git after every working change so you can roll back, and paste this checklist into your AI tool and ask it to verify each item. Then check its claims yourself with two test accounts. It will sometimes report a fix it didn’t make.

Get a written diagnosis before any quote. One solo peer advertises a fixed six-week rescue at $12K–$25K. My MVP builds start at $15K. Fractional CTO support from $6K a month fits founders who want to keep prompting with a senior reviewer on anything touching data, auth or payments.

Full breakdown with the scorecard and cost guide: https://akashbansal.tech/blog/vibe-coded-app-rescue-rebuild-or-keep-prompting/?utm_source=medium&utm_medium=referral&utm_campaign=vibe-coded-app-rescue-rebuild-or-keep-prompting

Akash Bansal, founding engineer: I build MVPs and AI products end-to-end for founders.

Written with AI assistance from my own notes and project experience. The full article, with sources, is linked above.

Founders get burned on code ownership in two different ways. Some don’t own the code on paper. Others own it on paper but can’t get to it, because the repository, cloud and app-store accounts sit in someone else’s name. You need both kinds of ownership.

On paper: the contract

In the US, copyright starts with whoever wrote the work. Employers own what employees write on the job. Contractors and agencies are different: their work counts as “made for hire” only if it fits one of nine categories in the law and there’s a signed agreement saying so (US Copyright Office, Circular 30). Software isn’t clearly one of those categories.

That’s why a contract that only says “work for hire” can fail for code. The fix is an explicit written assignment of copyright to your company, which US law requires to be signed. Good contracts include both, so ownership transfers even if the first clause doesn’t apply.

Also check when ownership transfers (“on full payment” vs “as created”), what pre-existing code the developer reuses and your licence to it, and how open-source components are disclosed. Other countries have their own rules, so ask a local lawyer.

In practice: the accounts

Your code repository, cloud, domain, Apple and Google developer accounts, payment account, third-party API keys and password vault should all be in your company’s name, with the developer added as a member. If any of these sits in a developer’s account, they control whether your product stays online, whatever the contract says.

Moving them later is possible but needs cooperation. Starting in your name is far easier than asking for it back during a dispute.

When AI writes the code

There are two layers.

Between you and the AI vendor, the terms generally give you the output. Anthropic’s commercial terms say the customer owns its outputs; OpenAI’s terms say you own the output and assign OpenAI’s rights, if any, to you.

Copyright itself is a different question. The US Copyright Office’s January 2025 report says copyright needs human authorship and prompts alone aren’t enough, while human work made with AI assistance can be protected case by case. In Thaler v. Perlmutter, the D.C. Circuit held in 2025 that a machine can’t be an author, and the Supreme Court declined to hear the appeal in March 2026.

In practice: your contract with the developer still matters most, human-reviewed and reworked code stands on firmer ground, keep the repository private, and run a licence check.

What if a developer already holds your code?

Ask calmly, in writing, and in order. Read the contract’s IP clause first. List every asset and where it sits today. Ask for account transfers to your company, not a zip file, because a zip leaves out history, settings and secrets. Move the accounts with the most leverage first: domain, payments, app stores, then cloud and repository. Rotate every password and key afterwards. Then have a different engineer deploy the product from what you received; if they can’t, the handover isn’t finished. If the contract only gives you a licence, or the developer refuses, talk to a lawyer before escalating.

How I set it up

On my builds the repository, cloud, domain, app-store and payment accounts are yours from day one, and I work inside them as a collaborator. Decisions are written down. If we stop, nothing has to be transferred, because none of it was ever mine.

The full checklist (before you pay, day one, during the build, at handover) plus red flags and what to do if a developer already holds your code: https://akashbansal.tech/blog/who-owns-the-code-founder-checklist/?utm_source=medium&utm_medium=referral&utm_campaign=who-owns-the-code-founder-checklist

Akash Bansal, founding engineer: I build MVPs and AI products end-to-end for founders.

Written with AI assistance from my own notes and project experience. The full article, with sources, is linked above.

The four biases

• Position: Evidence: Reordering flipped 66 of 80 comparisons (Wang et al., 2023); Containment: Absolute, one-item-at-a-time scoring. If you must compare, run both orders
• Verbosity: Evidence: Zheng et al., 2023; Containment: Content-specific criteria, and “length is not a criterion”
• Self-preference: Evidence: Self-recognition correlates with self-preference (Panickssery et al., 2024); Containment: The generator is never the only judge
• Intra-model: Evidence: A cross-family panel beats one big judge at >7× lower cost (Verga et al., 2024); Containment: An ensemble across providers

Pipeline 1: Brahmo (exam answers)

Event-driven, one job per stage:

1. Gemini OCR. Reading handwriting is its own problem, with its own output you can inspect.
2. Semantic matching against the expected points, so a correct idea in the student’s own words still gets credit.
3. Claude rubric scoring on weighted criteria. A different family from the reader.
4. Human-expert override. The pipeline proposes, and the expert decides.

The OCR model never judges, and the judge never reads raw handwriting, so errors can’t hide inside each other.

Pipeline 2: NextMantra (candidates)

Résumé-to-role fit and live-interview performance, each scored by multiple LLMs against the role’s rubric, outside the real-time voice loop, producing a ranked shortlist a recruiter reviews.

Rules I’d give anyone building one

1. Per-criterion scores with quoted evidence (close to the form-filling approach of G-Eval).
2. JSON schema per criterion: validate it, and retry or flag on failure.
3. Aggregate in code, with a disagreement threshold per criterion.
4. A gold set graded by humans, reported as quadratic weighted kappa (the ASAP essay-scoring metric) next to human–human agreement.
5. Treat model, prompt and rubric changes as code changes, and re-run the gold set every time.

Regulation

NYC’s Local Law 144 (bias audits for automated hiring tools) and the EU AI Act, Annex III (employment AI is high-risk) both push you towards the same design: documented criteria, per-score evidence, logs, and human override.

The full article, with tables and sources: https://akashbansal.tech/blog/multi-llm-scoring-llm-as-a-judge/?utm_source=medium&utm_medium=referral&utm_campaign=multi-llm-scoring-llm-as-a-judge

Akash Bansal, founding engineer: I build MVPs and AI products end-to-end for founders.

Written with AI assistance from my own notes and project experience. The full article, with sources, is linked above.

Ask three agencies what your app will cost and you’ll get three numbers that can’t be compared. Ask an online calculator and you’ll get a fourth, with no idea where it came from. The problem isn’t the numbers. It’s that none of them show their working.

So I built a calculator that does, and here’s the method.

Bottom-up, in four steps

The industry name is bottom-up estimation over a work breakdown structure. In plain terms:

1. List the scope. Platforms, types of user, features, integrations, AI parts.
2. Weigh each item in weeks. Not hours. Nobody can honestly estimate a login screen to the hour at the idea stage.
3. Price the weeks. I use $2,500 a week of senior-engineer time, which is my own MVP anchor ($15,000 for roughly six weeks).
4. Turn the point into a range. The high end is 30% above the low end.

The weights

A base of 3.75 weeks is always included: scoping and a design doc, the core workflow, cloud setup and monitoring, testing, launch and handover. Then each choice adds weeks. A few examples:

• Sign-up and login: +0.5
• Payments via hosted checkout: +0.75
• Admin dashboard: +1.0
• Booking, maps or chat: +1.5 each
• Any mobile app: +0.5; both stores: +0.5 more; web as well as mobile: +1.5
• Each extra type of user: +2.0
• An AI chatbot over your content: +3.0; an AI voice agent: +4.0

These are my rough estimates for a typical build, not measured averages. That’s the point of showing them: you can disagree with a line instead of disagreeing with a total.

Why the range only goes up

Steve McConnell’s Cone of Uncertainty (Construx) shows estimates made from an idea alone can be off by 4x either way, and well-defined projects get to about ±25%. I assume you’ve written your scope down, and I skew the range upwards because forgotten items are always additions. Nobody forgets a feature and finds it saved them money.

What typical apps come out at

• Lean web MVP (login, payments, admin): $15,000–$19,500, 6–8 weeks
• Mobile app on both stores: $19,000–$24,500, 8–10 weeks
• Booking app on the web: $20,000–$26,000, 8–10 weeks
• Two-sided marketplace, web only: $27,000–$35,000, 11–14 weeks
• Web + iOS + Android marketplace with three user types and ten features: $48,000–$62,500, 19–25 weeks

What it showed me

The biggest driver isn’t any feature. It’s the number of user types, followed by platforms, then AI and real-time features. Login, payments and notifications are cheap, because good hosted providers exist. If a quote prices them high, ask why.

What it leaves out

Regulated data, migrations, custom brand or design-system work, and third-party fees. They vary too much to be a checkbox. And it uses my rate; an agency with a project manager, designer and QA will price the same weeks differently.

How to use it

Untick features until the range scares you less. Write the survivors in a short PRD. Send the same document to every builder, and ask each for a breakdown by item. A quote that can’t say where the weeks go hasn’t been estimated yet.

The calculator: https://akashbansal.tech/tools/app-cost-calculator/?utm_source=medium&utm_medium=referral&utm_campaign=app-development-cost-calculator

Full breakdown with the cost table and the method: https://akashbansal.tech/blog/app-development-cost-calculator/?utm_source=medium&utm_medium=referral&utm_campaign=app-development-cost-calculator

Akash Bansal, founding engineer: I build MVPs and AI products end-to-end for founders.

Written with AI assistance from my own notes and project experience. The full article, with sources, is linked above.

Every founder eventually types “how much does an MVP cost” into Google and gets the same answer: somewhere between $3,000 and $300,000. Both ends are real. They’re just describing different products.

Public data shows the spread. Clutch’s September 2026 pricing guide gives an average app project of about $90,780, with most projects between $10,000 and $49,999. One agency’s 2026 guide says most MVPs cost $3,000 to $80,000. My own MVP builds start at $15,000 for roughly 6–10 weeks, with a fixed price after scoping.

The useful question isn’t what an MVP costs. It’s what’s in your version one.

The line items

A focused MVP (one type of user, one core workflow, payments, an admin view) has eight line items in any honest quote:

1. Scoping and a design doc. What’s in, what’s out, the data model, the schedule.
2. Screens for the core journey, on a proven component library.
3. Accounts and sign-up, on a standard auth provider.
4. The core workflow. The one thing your product does for users.
5. Payments, through hosted checkout.
6. An admin view, so you can run the business without an engineer.
7. Infrastructure: cloud in your accounts, monitoring, backups.
8. Testing, launch and handover, with documentation.

The core workflow should be the biggest item by a wide margin. When a quote is heaviest somewhere else (a custom design system, a feature-rich admin panel), it’s paying for the wrong things.

What moves the price

Not the hourly rate. Scope. Each of these adds whole weeks:

• A second type of user. Marketplaces need two of everything.
• Native-feeling apps on both stores. Device testing, push, review.
• Real-time features. Chat, live location, live updates.
• AI on real data. Testing on your inputs and controlling per-use cost. My AI features start at $8,000 on their own.
• Integrations. Each outside API has its own limits and failures.
• Regulated data. Health, finance, children.

After launch

Running costs at MVP scale are small: Apple’s developer program is $99 a year, Google Play is $25 once, Stripe charges 2.9% + 30¢ per US card charge, and hosting often starts on free tiers. The bigger cost is people: someone to fix what real users break. Budget for it separately.

When to spend nothing

If nobody has asked to pay you yet, don’t build an MVP. A landing page or a manual version tests demand for a few hundred dollars. A good builder will tell you that, even when it costs them the project.

How to compare two quotes

Put them on the same scope first. Send every builder the same one-page brief, then check six things in each quote: the scope is written feature by feature, including what’s out; the people doing the work are named; the price is fixed or capped, with a stated process for changes; ownership of the repository and accounts is yours from day one; launch and handover are included; and running costs, especially AI usage, are estimated.

Two quotes that are 3× apart usually describe different products. Once they describe the same one, the gap usually shrinks, and the remaining difference tells you something real about the builder.

Fixed price or hourly?

Fixed, once the scope is written. It puts overrun risk on the person best placed to estimate it. Hourly suits work you genuinely can’t scope yet, like a rescue of an unknown codebase. An hourly contract on an unclear MVP scope is how a five-figure budget quietly doubles without anyone lying.

Full breakdown with the cost table, a quote-comparison checklist and what’s not included: https://akashbansal.tech/blog/mvp-app-cost-2026-line-item-breakdown/?utm_source=medium&utm_medium=referral&utm_campaign=mvp-app-cost-2026-line-item-breakdown

Akash Bansal, founding engineer: I build MVPs and AI products end-to-end for founders.

Written with AI assistance from my own notes and project experience. The full article, with sources, is linked above.

When a non-technical founder asks me “should I find a technical cofounder or hire an agency?”, I usually answer with a different question: what are you willing to pay with?

Each option charges a different currency.

A technical cofounder charges equity. In Carta’s 2025 data on more than 9,000 US founding teams, 46% of two-founder teams split exactly 50/50, and the median was 51/49. If you want a true technical partner, expect to give close to half the company. In return you get someone tied to the outcome for years.

A full-time founding engineer charges salary plus a small grant. Carta reports a median equity grant of 1.54% for a startup’s first engineer. You keep control, but you need the money to pay a senior salary every month, and the roadmap to keep them busy.

An agency charges cash, and usually the most of it. Clutch’s September 2026 pricing guide gives an average app project of about $90,780 and an average timeline of about 11 months. Agencies are built for large, well-specified projects with many specialists. MVPs change every week, and every change goes through a project manager.

A freelancer charges your time. The rate looks low, but you write the spec, judge the technical choices and manage the work.

There’s a fifth option, the one I work in: an independent founding engineer. A senior engineer who makes the technical decisions and builds version one for a fixed price, with the code and accounts in your name from day one, while you keep your equity.

How I’d choose at each stage

Before validation: none of them. If you can’t show that anyone wants this, don’t pay anyone to write code. A landing page, a no-code tool, or doing the service by hand for your first ten customers will tell you more for a few hundred dollars.

The technology is the moat: a cofounder. If the hard part is technical (new models, hard infrastructure), you want someone who’ll care about your architecture in year four. That takes equity. Put it on a four-year vesting schedule with a one-year cliff, and do a short trial project together before signing anything.

Validated, not yet funded for a team: an independent founding engineer. You need a real product in weeks, someone senior making the calls, and you don’t want to give away a third of the company to get it.

Funded with a long roadmap: hire full-time. At that point a full-time engineer is cheaper per hour of work than anyone external.

A big, stable spec: an agency. Name the engineers in the contract, and keep the repository and cloud in your name.

The thread that runs through all of them

Every option has a predictable failure. Cofounders break up and walk away with large stakes. Agencies sell with senior people and build with junior ones. Freelancers disappear. A single independent engineer is a single point of failure.

The protection is the same in every case: own the code and the accounts from the first commit, and get the decisions written down.

I spent five years as head of technology for a marketplace that grew to 500K users, built an AI hiring platform solo, and now build first versions for founders. From each seat the lesson was the same: decide your stage first, then the option.

Full breakdown with the cost table and decision tree: https://akashbansal.tech/blog/technical-cofounder-vs-founding-engineer-vs-agency/?utm_source=medium&utm_medium=referral&utm_campaign=technical-cofounder-vs-founding-engineer-vs-agency

Akash Bansal, founding engineer: I build MVPs and AI products end-to-end for founders.

Written with AI assistance from my own notes and project experience. The full article, with sources, is linked above.

The stack

• Next.js front end, NestJS API, PostgreSQL
• Interview agent: Python + FastAPI running a Pipecat pipeline
• Daily WebRTC rooms, with the bot joining as a participant
• Groq for in-call inference
• Multi-LLM scoring after the call
• AWS defined as code, deployed through an AES-encrypted, tamper-evident pipeline

The budget, with public numbers

Daily’s team targets an 800 ms median voice-to-voice time (their write-up). Their stage numbers: streaming STT fragments in about 100 ms, TTS first byte as low as 80 ms, and an SF to NY round trip around 70 ms. LLM first-token time is the wide one: 80 ms for self-hosted Llama 3 70B, roughly double for the fastest hosted services, 300–400 ms for larger frontier models, and 500–1,500 ms for typical hosted APIs.

Add turn detection. Pipecat’s Smart Turn guide pairs the model with a 0.2 s VAD stop. That’s silence you wait through before any compute starts.

Where it actually hides

• Prompt length → TTFT. Interview prompts are long (role, rubric, résumé, plan, history). Benchmarks like Artificial Analysis are useful, but test at your input length.
• Not streaming. Sentence-level LLM → TTS → room streaming. Frameworks do this. Glue code often doesn’t.
• Distance. Colocate the bot with the vendors it calls. Daily’s write-up puts the colocation saving at 50–200 ms.
• Cold starts. Measure the first turn separately from the steady state.

Interview-specific

Candidates think out loud (“I’d approach that by… hmm…”), so tune turn detection for patience, not speed. Keep the question plan as explicit state in code. Handle barge-in in both directions. Store a timestamped transcript, because it becomes evidence.

Pipecat or LiveKit?

Pipecat is a Python pipeline that runs over several transports (Daily, WebSockets, telephony). LiveKit Agents is built on LiveKit’s own WebRTC server and has Python and Node SDKs. Spend a day building the same three-turn flow in both, on a phone with a bad network, and measure.

Keep judgement out of the loop

The live model should be fast. The scoring should be careful. Splitting them gives you both, and lets you score with multiple model families against a rubric. That’s covered in a separate post.

The full article, with tables and sources: https://akashbansal.tech/blog/building-a-real-time-ai-voice-interviewer-solo/?utm_source=medium&utm_medium=referral&utm_campaign=building-a-real-time-ai-voice-interviewer-solo

Akash Bansal, founding engineer: I build MVPs and AI products end-to-end for founders.

Written with AI assistance from my own notes and project experience. The full article, with sources, is linked above.