Design + engineering for SaaS founders
Stripe-integrated checkout, multi-tenant auth, dashboards that surface value before churn. The whole subscription product, not just a landing page.
The problems we hear most
Stripe and Customer.io and Intercom and a Google Sheet for trial extensions
Five tools, none of them talk to each other, nobody knows how many weeks of runway burn each month.
A founder hand-fixing onboarding events at 11pm
No activation tracking, no funnel view, no way to tell which step is killing conversion. Decisions made on vibes.
Dashboards that say what but never why
Your customers churn and your team finds out from the cancellation email. Value never surfaced where it mattered.
A pricing page that talks to engineers, not buyers
Plans copied from a competitor, comparison table no one reads, no usage metering tied to billing.
Moko · eight surfaces, one design system
A customer support workspace, designed and built whole. Inbox, ticket detail, customers, knowledge base, reports, macros, settings, customer portal. Eight production surfaces, one design system, one team.
Inside the Moko build
Moko replaces the day-to-day surfaces a support team lives in: inbox, ticket detail, customers, knowledge base, reports, macros, settings, and the customer portal. The brief was that every surface gets the same level of finish, not a polished hero followed by seven half-built drawers. That is the shape of work that breaks most support tools after launch: the inbox gets all the attention, the reports never get the same care, the customer portal is an afterthought. We treated all eight as equal, and the design system absorbed the cost of doing it.
The design system was the project
Eight surfaces sharing one finish means the design system carried the project, not the other way around. We started by building the components that the inbox, the customer profile, and the reports would all share, namely buttons, badges, status pills, modals, dropdowns, table rows, and charts, and then assembled the surfaces on top of that foundation. No screen got special treatment, no surface negotiated for a one-off variant, and the team that ended up using the system at scale was small enough that consistency was a feature, not a process burden.
The keyboard-first inbox
The inbox is the single most important page. A support agent moves through it constantly. The composer toggles between public reply and internal note with a colour change that makes the mode unambiguous before send. Status changes are optimistic with rollback, so the UI never blocks on a network round-trip. Tags and priority are edited inline, never in a dialog. An AI summary card sits above threads with three or more messages and surfaces sentiment, plan context, and a suggested next step. A one-click refresh re-rolls the suggestion when the agent wants a different angle.
Five keyboard shortcuts cover the inbox: navigate the conversation list, move between status states, open the AI summary, insert a macro, send the reply. The help overlay teaches them in the same place they are used. Power users never reach for the mouse.
A customer profile that does not lie
Customers carry their own history with them. The 360 profile pairs a stats strip with the full ticket list and a custom-fields editor that adds, edits, and removes inline with optimistic feedback. The same shape powers the inbox drawer, so an agent who opens a conversation already sees the customer's plan, location, lifetime CSAT, and last few tickets without leaving the thread. No tab switching, no waiting for a sidebar to load. One shape of data, used in two places.
A knowledge base that is two products in one
The admin side is a CMS for support content with categories, drafts, and published states. The public side, served at /help, is a marketing-style layout with hero search, category cards, and per-article table of contents. Both sides read from the same data, so an agent updating an article does not have to think about which surface their readers will see it in. The same article that anchors a support reply is the article a self-serve customer finds via search.
Macros as a templating system
Macros are not a quick-reply menu. They are a lightweight templating system. Variables resolve from the live ticket and customer at the moment the agent inserts the macro, so the same template feels written for the person on the other side. The combination of macros, the AI summary card, and inline edits is what turns the inbox from a list into a workspace.
Light and dark from the first commit
Every surface ships in both themes from the first commit. The whole product is token-driven: no hardcoded colour, no hardcoded font weight, no inline style anywhere in the codebase. The design system carries the palette, the type scale, the radii, and the elevations across both themes. Charts and badges read from the same tokens as the buttons, so a theme switch never lies about what is interactive. Four chart types live in the reports surface; each one is wired to the design system tokens, so a colour change in the system propagates across the product in a single commit.
Why this shape matters for a SaaS founder
A complete SaaS is not a marketing site plus an MVP. It is the inbox the support team works in, the ledger the finance team reads, the reports the founder checks before a board meeting, and the portal the customer logs into to manage their plan. Moko is the shape of work that does that whole loop with one design system, not eight teams stitching eight inconsistent surfaces together. The result is a product that does not need to be rewritten when the team grows or the brand evolves.
What the work delivered
Eight surfaces under one design system. Five keyboard shortcuts in the inbox. Four chart types tied to design tokens. Zero hardcoded values across the codebase.
What we deliver for this vertical
Multi-tenant auth with Supabase RLS
Row-level security that survives audit, tenant isolation enforced at the row.
Stripe billing with prorating
Checkout, Subscriptions, Customer Portal, webhook event router.
Onboarding with activation tracking
Funnel events tied to the actions that actually predict retention.
Admin dashboard
Internal cockpit for support, refunds, plan migrations.
Webhook event router
Idempotent handlers, retry queue, dead-letter logging.
Role-based permissions
Owner, admin, member, billing. Enforced server-side, not just in the UI.
Usage metering
Tie consumption to plan limits and downstream invoicing.
Free-trial abuse prevention
Email + fingerprint heuristics, no reset-by-incognito loophole.
API surface
Versioned, documented, rate-limited. Customers stop emailing for one-off CSV exports.
Feature flags
Ship in a branch, roll out by tenant, kill switch on call.
Audit log
Every privileged action attributable, exportable, queryable.
GDPR data export and delete
Self-service, single-button, no engineering ticket.
A stack that matches the SaaS lifecycle
Every layer here exists to pay for itself twice. Once when you are shipping the first version of the product, once when you start scaling, hiring, or facing the hard questions of an enterprise customer's procurement team. We pick the stack that holds up in that second moment.
Your marketing site, your in-app dashboard, and your admin panel all live in one codebase, built on Next.js App Router. The pricing page ranks on Google like a static site, the dashboard loads fast on the user's first click, and your engineers never argue about which framework owns the signup flow. One repo, one deploy, and the marketing team and the product team work in the same place.
Customer data is isolated at the database level, not in application code, and that is the point: the first enterprise deal you chase will go through a security review, and that review will always ask the same question, namely how you guarantee that customer A cannot see customer B's data. With Supabase Postgres and row-level security the answer is provable in a single screen of code, and you can put it in writing. The same database also handles user accounts, file uploads, and real-time updates, so you are not stitching together three different services that disagree on who the user is.
Subscriptions, plan upgrades and downgrades, payment retries, invoices, refunds, all built on Stripe Subscriptions and Customer Portal, so the billing layer grows with the product instead of asking for a rewrite once you start to scale. We wire the moving parts so that a Stripe outage does not leave your billing records out of sync. Customers manage their own plan, cancel, reactivate, download receipts, and support stops being the billing department.
Infrastructure that does not run away in cost as the product grows: Upstash Redis at the edge takes care of rate limiting and abuse protection without you provisioning a server, while Cloudflare R2 stores customer files, so a user hitting the same file at scale does not turn into a four-figure surprise on the invoice. Predictable costs, no surprises.
Every API call, every database query, every UI element is type-checked with TypeScript. The benefit is unglamorous and load-bearing: when someone leaves the team, when you replace an engineer, when you rename a feature, the product does not silently break. The next person who opens the codebase can navigate it without a guided tour.
Questions founders ask
What if I already have an MVP in Bubble?
We migrate. The Bubble logic gets translated into real code, the data moves to Postgres, and the new product ships as a proper application rather than a no-code prototype with a ceiling.
Can you build only the billing layer?
Yes, with a clear perimeter. Stripe Checkout, Stripe Subscriptions, and Customer Portal as a contained module, with the webhook handlers wired in and an admin view for your team. Scope and price scale with how complex the pricing model is.
How do you handle free-trial reset abuse?
Email-domain heuristics, browser fingerprinting at signup, and a hard cap on retries per IP and device. We treat it as a security layer, not a marketing nicety.
Do you set up activation analytics or do I bring my own?
Either. We have a default we trust (PostHog plus a small server-side wrapper) and we will plug into whatever tool you already pay for.
What is the smallest scope you will ship to get to paying customers?
Authentication, billing, and one core workflow done well. Dashboards, admin views, and integrations come after paying customers tell you which one to build first. We trim aggressively before the build, not after.
Do you stay on after launch?
Either a clean handover with documentation and design system in the hands of your team, or we stay on as an ongoing product partner. We do not vanish.
What if I want to keep my agency for marketing?
Fine. We build the product surface, they keep the brand site, and we coordinate on a shared CMS and analytics so neither side is blind to what the other is doing.
How much does a complete build cost?
The contact form has the range. After a scoping call to understand what you are building we answer with a concrete number, not a brochure.
Tell us about your SaaS
A scoping call, a concrete number in the first reply, no agency theater.