Two dedicated engineers. One TypeScript stack. A build we can defend line by line.

Prepared for Anant Pawar at Confetti Design Studio, for the pre-launch commerce platform Confetti is assembling a technical delivery team for.

We are two engineers who work together as a fixed pair on every project. On this build one of us is dedicated full-time to the backend and one dedicated full-time to the frontend. Neither role is shared with another client for the duration of the retainer, which is the specific thing your brief asked us to confirm.

The short version of what follows:

Stack

Next.js 15 and React 19 across the consumer application, the admin portal and the API, in one repository. PostgreSQL, Redis and BullMQ behind it, with a separate Node worker process for queued and scheduled work. One framework, one language, end to end. Magento is not involved anywhere.

Hosting

AWS ap-south-1, Mumbai, for every stateful component. This is driven by your India data residency requirement, not by preference.

Scope

All fourteen V1 functional areas and all three surfaces. Nothing tagged T1 is priced or planned.

Timeline

13 working weeks of frontend and backend, running in parallel from day one, plus a 3 week hardening and launch phase. Testing is inside every week, not appended to the end.

Cost

₹2,00,000 per month as a retainer, absorbing unlimited reprioritisation within monthly capacity. Vendor and cloud costs are pass-through, itemised in section 10.

Pushback

Three items in your V1 need a decision from the client before we can build them correctly, and one may not exist as an integration at all. Section 13.

One dedicated backend developer. One dedicated frontend developer. Both full-time, both on this build only, for the length of the retainer.

Backend, 1.0 FTE

Ayaan Retiwala, platform engineer. Spent three years building and operating the core of a public cloud: the compute control plane, a block storage engine, managed Kubernetes, the identity and IAM plane, an S3-compatible object storage API, and authoritative DNS. At handover that platform ran 4,000 accounts and 140 managed Postgres clusters, and he took production escalations directly. On this build he owns the API, the data model, every vendor integration, the job queue, the payment and ledger paths, and the AWS infrastructure and CI/CD.

Frontend, 1.0 FTE

Dhrumil Kherde, product designer who writes and ships production frontend code. Five years designing multi-role platforms, including a clinical intelligence product spanning patient, clinician and admin personas, and a risk management platform covering admin and end-user workflows. Built WCAG-compliant component and data-visualisation libraries. Owned both design and engineering on an AI proposal platform through to deployment. On this build he owns the consumer application, the four role-gated admin views, the component library built from Confetti's design, accessibility, and the Core Web Vitals target.

QA and DevOps

Held inside the pair, not outsourced and not a separate line item. Both of us write tests, both of us review, both of us are on the deployment pipeline. At this team size a handoff to a separate QA function costs more than it catches.

Scaling up

If scope grows past what two people can absorb, we add a third engineer at the day rate in section 11 rather than quietly slipping the date. We will tell you when we think that point is coming, before it arrives.

Why the frontend seat matters more than usual here

Confetti owns the design, which means the frontend seat is really a translation seat. Our frontend is a practising product designer, so the Figma file gets read the way it was meant, spacing systems and component variants survive the trip into code, and the edge cases your designers did not draw get raised as questions rather than invented in code.

Practically: fewer clarification threads back to your design team, and a build that still looks like the file when it ships. If Confetti works in components and variables, we will consume them as tokens directly rather than eyeballing values.

One framework across both seats, a modular monolith rather than microservices, and every third-party vendor behind an interface we control.

The four choices worth justifying

One framework, one language, one repository

With two dedicated engineers, fewer moving parts is worth more than picking the theoretically best tool for each layer. Next.js covers the consumer application, the admin portal and the API in a single codebase, so there is no separate API service to deploy, no client generation step, and no drift between what the server returns and what the screen expects. Types are shared by direct import rather than by a code generator. Server Components remove the API layer entirely for our own screens, which leaves a deliberately small public surface: webhooks, the two WhatsApp bots, and the public certificate verification route. Python or Java for the API would each be defensible on their own, and would cost us all of that.

Inside that codebase, every functional area in your section 4 is its own module in packages/core with its own boundary and tests. That gives us the separation people usually reach for microservices to get, without the distributed tracing, network failures and deployment overhead a two-person team cannot afford to run. If a module genuinely needs to scale on its own later, the boundary is already drawn.

Where Next.js stops, and what sits beside it

Worth being direct about the boundary, because this is where a Next.js backend is usually oversold. A request handler is the wrong place for work that has to survive a crash or run on a schedule. Notification delivery, payout batches, product-lock expiry and rate-feed polling run in a separate Node worker process from the same repository, consuming BullMQ queues and importing the same packages/core modules the application uses, so a business rule exists in exactly one place and cannot drift between the two.

That worker is a second entry point, not a second framework. Both it and the application run as long-running containers rather than serverless functions, which is what makes database connection pooling and a persistent queue consumer possible at all. Deploying Next.js serverless would have ruled out both, and that is the main reason the platform layer is ECS rather than the obvious default.

AWS Mumbai for everything stateful

Your brief requires India data residency for Indian users. That rules out the usual convenient defaults, where the application is edge-deployed globally and the database quietly sits in Virginia. Primary data, replicas, backups and object storage all stay in ap-south-1. Static assets are cached globally through CloudFront because cached public images are not personal data, and everything that is personal data stays in region.

The adapter layer is real code, not a promise

Your brief asks for every integration to sit behind an internal abstraction so it can be swapped without a rewrite. Each of the nine categories is a TypeScript interface with an implementation per vendor. Application code depends on PaymentProvider, never on Razorpay. Each implementation runs against the same contract test suite, so swapping vendors means writing one new class and passing the same tests. This is also our hedge on the domain assumptions in section 01: if the profile computation turns out to be something other than what we have assumed, only the implementation behind ProfileComputeProvider changes.

All fourteen functional areas from section 4 of your brief, with the approach named for each. Nothing tagged T1 appears here or in the price.

Three surfaces, two deployments, one identity

The consumer application and the admin portal are separate deployments from one monorepo, sharing a component library and the same domain modules. They are split because an external Affiliate Partner logging in to reach commission statements should not be served from the same origin as the Admin and Ops console. Both authenticate against one identity service, so a person is one record whether they arrive by web, portal or WhatsApp. The two WhatsApp bots are handlers on the same API, not a separate system.

Most of this scope is well-understood work. Five parts are not, and they are where a build like this usually goes wrong. Here is how we intend to get each one right.

The 60-minute product lock with a forfeitable deposit

This is the hardest requirement in the brief and it is easy to underestimate. Every item is unique, so two customers can reach the same item in the same second. A lock also takes real money, which means an expiry bug is not a display glitch, it is a refund dispute.

We hold the authoritative state in PostgreSQL with row-level locking, and use Redis only as the fast path for reads, never as the authority. Acquiring a lock is a single atomic transition from available to locked, so the second customer gets a clean refusal rather than a second lock. The deposit is a real capture through the gateway, tied to the lock record. Expiry is a scheduled job placed at the exact expiry time rather than a periodic sweep, so release is precise. Whether an expired lock forfeits or refunds is a policy value on the record, not a branch in the code, so the client can change the rule without a release.

Pricing that moves without repricing customers mid-checkout

A live rate feed and a shopping cart are in direct tension. If the rate updates between add-to-cart and payment, a customer who saw one number is charged another, and that is a chargeback. We snapshot the computed price and its full breakdown onto the cart line at add-to-cart, with a stated validity window. The snapshot is what gets charged. If the window lapses before payment, the customer is shown the change explicitly and asked to accept it rather than being silently repriced.

Live sessions only the buyer can watch

The common mistake is letting the streaming vendor own access control, which usually ends with a recording URL that works for anyone who has it. Entitlement lives in our database. Our API checks it and mints a short-lived signed playback token, and the vendor only validates the token. Recordings are gated identically, so a session someone paid for does not become a public link six months later.

A commission ledger that survives an argument

Affiliate money attracts disputes, so the ledger is append-only and double-entry: nothing is ever updated in place, corrections are new entries. Attribution is captured when the event happens and frozen at conversion. Payouts are prepared as a batch that a human reviews and approves before it executes, because an automated transfer with a bug in it is unrecoverable in a way a wrong screen is not.

Notifications that cannot double-send

Your brief asks for transactional notifications without duplicates, across three channels. Duplicates almost always come from retries: a worker crashes after sending but before recording that it sent. The transactional outbox pattern fixes this at the root. The notification intent is written in the same transaction as the state change, so it can never be lost, and delivery carries an idempotency key, so it can never be repeated. Channel selection sits behind the messaging adapter, which is what lets us launch on SMS and email and swap WhatsApp in the day Meta approves the account.

Your section 5 asks for specific numbers rather than adjectives, so these are the numbers we will hold ourselves to.

Uptime target

99.9% monthly on the consumer storefront, measured by external synthetic checks, not by our own dashboards. That is roughly 43 minutes a month. We would rather commit to a number we can hold than quote 99.99% and miss it.

Core Web Vitals

LCP under 2.5s, INP under 200ms, CLS under 0.1, on a mid-range Android over 4G, on the HD-imagery pages specifically. Budgets are enforced in CI: a pull request that breaks them fails the build rather than being noticed after launch.

Scaling

Stateless services auto-scale on request rate and CPU. Static assets and images are absorbed by the CDN, which is what actually carries a traffic spike on an image-heavy catalogue. Load tested against a defined peak before launch, not after.

Encryption

TLS 1.3 in transit. Encryption at rest on the database, object storage and backups with managed keys. Card data never touches our infrastructure or the client's, so PCI scope stays at the lowest self-assessment tier.

Access and audit

Role-based policies evaluated per request. Every privileged action writes an append-only audit entry with actor, timestamp, and before and after state. Audit records are not deletable through the application.

Secrets

Held in AWS Secrets Manager and injected at runtime. Automated secret scanning runs on every commit, so a key cannot reach the repository history in the first place. No shared credentials between environments.

Consent and retention

Consent is captured as a versioned record naming what was agreed and which policy version was in force. A written retention schedule per data class, enforced by scheduled deletion jobs rather than by intent. Export and deletion endpoints for subject requests.

Data residency

All personal data, replicas and backups stay in AWS ap-south-1, Mumbai. No cross-region replication of personal data. Where a vendor cannot guarantee India residency, we say so in section 10 rather than quietly routing data abroad.

Backups and recovery

Automated daily snapshots with point-in-time recovery. Target RPO 15 minutes, RTO 4 hours. Your brief asks for a tested disaster recovery process, so we run a full restore drill before launch and once a quarter after, and give you the written result each time.

Observability

Structured logs, metrics, distributed tracing, and error tracking with alerting into a channel the client can see. Alerts are tied to user-visible symptoms rather than to CPU graphs, because the second kind gets muted within a month.

CI/CD

Three environments, development, staging and production. Every merge deploys to staging automatically. Production releases are tagged, migrations are gated and reversible, and rollback is a single action. Staging stays permanently available for Confetti and the client to click through.

Vendor independence

Nine adapter interfaces, one per integration category. Application code never imports a vendor SDK directly. Every implementation is validated against a shared contract test suite, so replacing a vendor means writing one class and passing the same tests.

Two-week sprints against a milestone plan, with a working staging environment from the end of week two so nobody is judging progress from a status document.

Cadence

Two-week sprints. A demo of working software on staging at the end of each, not slides. Written async standup daily in a shared channel with Confetti.

Weekly report

Four things every Friday: what shipped, what is next, what is blocked and on whom, and what changed in scope this week. The last item is the one that keeps a retainer honest.

Staging

Permanently live from week two, open to Confetti and the client. Every merged change appears there automatically, so feedback happens continuously instead of arriving at UAT.

Definition of done

Merged, covered by tests, deployed to staging, and demoed. Work that is written but not deployed is not counted as done in any report we send you.

Decisions

We need one named product owner on the client side who can sign off without escalation. Decisions get logged in a running document with the date and the reason, which is what makes a mid-project scope conversation short.

Code and IP

Repositories live in the client's organisation from day one, not ours. All work product transfers to the client on payment. There is no handover event to negotiate at the end because there is nothing we are holding.

Milestones

Thirteen weeks of frontend and backend running in parallel, which is three months and sits inside your two to three month target. Three further weeks of hardening and launch. Sixteen weeks total from our start date.

How this fits your four-month target

Your brief puts design at roughly two months and full delivery at four. Backend work does not depend on design, so it starts on day one: the data model, identity, the pricing engine, the integrations and the admin API can all be built against an agreed contract while design is still in progress. Frontend spends the first two weeks turning Confetti's tokens and components into a library, then builds screens as they are finalised, section by section, rather than waiting for a complete file.

That parallelism is what makes sixteen weeks possible rather than the twenty-four you would get by running design, then backend, then frontend in sequence. It has one condition, which is that Confetti releases design in slices as it is settled instead of holding it for a single handover. We would rather have the navigation and the product page in week three and the rest later than the whole file in week nine.

Roughly a quarter of every sprint's capacity, inside the sprint. Testing is not a phase at the end, because a phase at the end is the first thing sacrificed when a date moves.

Unit tests

Weighted towards the code that handles money and state: the pricing engine, the lock state machine, the commission ledger, entitlement checks, and refund and buyback flows. Everything else gets proportionate coverage rather than a coverage percentage chased for its own sake.

Integration tests

Run against vendor sandboxes, including the failure paths. Payment declines, webhook replays, delivery failures and rate-feed outages are tested deliberately, because those are the cases that reach a customer.

Contract tests

One suite per adapter interface, run against every implementation. This is what makes the vendor-independence requirement verifiable rather than a claim.

End to end

Playwright covering the journeys that carry revenue: browse, lock, checkout, order, book a consultation, verify a certificate, complete the diagnostic, and access a paid live session. Run on every pull request.

Performance

Core Web Vitals budgets enforced in CI on real page weights. A full load test against a defined peak before launch, with the results shared.

Accessibility

WCAG 2.1 AA on the consumer application. Automated checks in CI, plus manual keyboard and screen-reader passes on the checkout and booking flows, which automated tooling does not reliably catch.

UAT

A structured pass with the client in M5 against a written script, so acceptance is a checklist both sides agreed to rather than an opinion formed on the day.

The services below are our proposed V1 choices. The costs are working launch estimates rather than descriptions of a pricing model. Where usage drives cost we have included a reasonable early-production assumption, so the client has an actual operating budget to work from rather than a shrug. Final numbers get recalculated against expected traffic, order volume and the full specification at kickoff.

A monthly retainer buying dedicated capacity, structured so that changing your mind mid-project costs nothing as long as the total does not grow.

Negotiable

This figure is priced against section 4 as we have read it, and it is negotiable. If your budget envelope is a different number, tell us what it is and we will come back with what genuinely fits inside it. We would rather adjust the scope openly than agree to a figure and quietly thin out the testing, the observability or the parts of section 6 that are difficult to see from the outside.

Reprioritisation

Free and unlimited. Swap work in and out, reorder the backlog, change your mind about a module's behaviour. As long as the month's total does not grow, it costs nothing and needs no paperwork. This is the part of a retainer that has actual value and we are not going to charge you for using it.

Net additions

When new scope pushes past the month's capacity, we tell you before we start and you choose: schedule it into the following sprint at no extra cost, or add capacity at ₹6,000 per engineer-day. We will not do the work first and invoice for it afterwards.

Term

Three months minimum, then rolling monthly with 30 days' notice on either side. Invoiced monthly in advance.

Adding a third engineer

If scope grows enough to need one, an additional dedicated engineer is ₹1,00,000 per month. We will flag when we think that point is approaching rather than absorbing it silently and missing the date.

Not included

Vendor subscriptions and usage fees, cloud infrastructure, payment gateway charges, laboratory certification fees, product photography, and written content. All pass-through at actual cost, billed directly to the client's own accounts.

After launch

The retainer can step down to a maintenance and support tier at ₹85,000 per month, covering monitoring, incident response, dependency and security updates, and a defined allowance of small changes. The T1 roadmap items would be quoted separately.

Ownership

All code, infrastructure definitions and documentation belong to the client. Repositories sit in the client's organisation from week one.

Everything below is priced on the basis that these hold. If any of them are wrong, tell us now and we will reprice rather than discover it in week six.

1. The domain reading in section 01 is roughly right. If the product category, the raw material or the nature of the profile computation is materially different, the architecture holds but the vendor selection in section 10 changes.
2. Confetti delivers design in slices, not one handover. Navigation, the design system and the product page by week three, the rest progressively. Frontend velocity is directly coupled to this, and it is the single largest schedule dependency we have that is not ours.
3. Design arrives as a component library with states. Hover, focus, disabled, loading, empty, error and long-content states defined. Where they are not, we will make a call and flag it rather than stopping.
4. The client provides business documents in week one for payment gateway KYC and Meta business verification. Both are queues we cannot shorten.
5. One named product owner on the client side with authority to sign off without escalation.
6. The client supplies content and photography. Product copy, editorial content, legal pages, and the HD product imagery. We build the pipeline that processes and serves it.
7. The certification laboratory is named in week one so we can establish what, if anything, is integrable. See section 13.
8. English only for V1. Secondary-language parity is tagged T1 in your brief. We will not hardcode strings, so adding a language later is translation work rather than a rebuild.
9. Written policy decisions before we build the modules that depend on them: the deposit forfeiture rule, the returns and buyback terms, and which currency is settlement versus display.
10. Reasonable working hours. Full-time dedicated on this build, IST, with overlap for calls. Not on call overnight during development, though we are during the launch window.

Your brief asked us to say if something looks over-scoped or wrong, and to propose an alternative rather than just flagging it. Four things, in order of how much they worry us.

1. The certification integration may not exist

Your section 6 asks us to name and cost "any accredited verification integration". As far as we can establish, accredited laboratories in this space issue physical certificates and, at best, publish a report-number lookup on their own website. There is no general certificate issuance API to buy and integrate.

What we propose instead: we build the certificate record store, the public verification tool and the QR resolution ourselves, which is section 10's line for this. Where the named laboratory offers a lookup, we integrate it as a verification step. This is cheaper than the brief implies rather than more expensive, but it needs the laboratory named in week one, because the answer differs by lab.

2. "Photo intake" on the Efficacy Meter hides an unstated requirement

The Efficacy Meter is described as a free diagnostic with photo or questionnaire intake and a scored result. If the photo is meant to be scored automatically, that is a computer-vision problem with data collection, model training and an accuracy standard behind it. That is a separate workstream, not a form.

What we have priced: a rules-based scored questionnaire with optional photo upload, where the photo is stored and surfaced for human review by the in-house specialist. The scoring rules are held as data so the client can tune them without a deploy. If automated photo analysis is genuinely intended for V1, we need to discuss it separately, because it changes both the timeline and the team.

3. The unique-SKU lock needs a policy before it needs code

A 60-minute lock backed by a forfeitable deposit on one-of-one stock is a commercial policy wearing a technical costume. What happens when a customer's payment succeeds but the lock expired thirty seconds earlier? What happens if two customers pay simultaneously and one must be refunded? Is the deposit forfeited on expiry, on cancellation, or only on a completed lock the customer walks away from?

What we need: a written policy from the client before M2 begins in week six. We will draft a proposed version in M1 so the client is reacting to something concrete rather than starting from a blank page. The code is straightforward once the rule is decided, and expensive to change afterwards because it touches money already taken.

4. Four external dependencies own the critical path, and none of them are ours

We are committing to the timeline in section 8. The honest caveat is that four things sit outside our control, and if they slip the date slips with them. All four need to start in week one.

The pattern in the right-hand column is deliberate. Every integration sits behind an adapter, which means a blocked vendor stops us from verifying a path, not from building it. That is the practical reason the abstraction layer your brief asked for is worth its cost.

Two smaller notes

On the admin portal. One codebase with four role-gated views is the right call and we have priced it that way. We recommend deploying it twice, on separate origins, so external Affiliate Partners are not served from the same host as the Admin and Ops console. Same code, same identity system, better separation. It costs almost nothing to do and is difficult to retrofit.

On the T1 roadmap. The deferred AI concierge will need the catalogue, the profile data and the consultation history modelled in a way it can query. We will model with that in mind now, at no additional cost, so that building it later is an addition rather than a migration.

Confetti owns design on this engagement, so this section is deliberately brief, as your brief requested. A team of senior UI and UX designers will be allocated by Confetti to meet all UI and UX requirements across mobile and desktop, and our role is to implement that work faithfully. On our side, the frontend seat is held by a practising product designer, which means Confetti's files are read as intended, the component library and design tokens are consumed directly rather than approximated, and gaps in the design are raised as questions rather than filled in by guesswork.

If we are shortlisted, here is what we would want from a first conversation, and what we would do straight after it.

What we would ask for

The full specification Confetti is holding, the client's category and the identity of the certification laboratory, the intended design delivery dates, and a decision on whether automated photo analysis is in scope for the Efficacy Meter.

What we would deliver in week one

A written architecture document and data model for sign-off, the three environments provisioned, and the vendor account checklist issued so the approval queues start immediately.

Start date

We can begin within one week of a signed agreement. Backend work starts immediately and does not wait for design.

Questions before then

Anything in this document that reads as wrong is more useful to us as a correction than as a reason to rank us lower. We would rather rewrite a section now than discover the mismatch in month two.