Software your customers log into — not another email to your support queue.
This is software customers log into: a portal, an account dashboard, a status page, a booking tool — whatever today still means “email us and wait.” We design and build it end to end so it ships as a real product surface, not a prototype that needs another six months before anyone can use it.
We typically ship on a small stack — Svelte on the front, Supabase for auth, data, and storage — because it gets a production-grade tool out in weeks, not a quarter. Prefer your engineering team’s stack? We build against that. The point isn’t the tech. It’s a tool customers can finish the job in.
Fixed price, fixed scope. We agree the first shippable version up front, ship it, and treat anything discovered after as a clear follow-on — not quiet scope creep on the original build.
Email-us vs self-serve, in practice
Customer asks. Someone digs up status, reschedules by hand, or digs for a PDF. Works until volume spikes — then support becomes the product.
Customer logs in, finishes the job, leaves. Live data from systems you already run — not a synced copy that drifts.
We don’t rebuild your whole platform. We ship the one surface that stops the inbox from being the UI.
How a customer product ships
One job → fixed scope → design the path → build against live systems → hand over ownership.
- 01JobThe one thing they email for
- 02ScopeFirst shippable version, priced
- 03PathUI/UX for the real flow
- 04WireCRM, billing, support — live
- 05HandoffSource + deploy, yours
Built on the stack you can keep
Default stack for speed — or yours, if your team already owns one. Either way, you maintain it after handoff.
Anatomy of a self-serve job
Login → the job → done. Happy path finishes without your team. Fail path escalates with context — not a dead end.
Status · reschedule · invoice — live from your systems
Escalate with account context — no “please email support” void
When this makes sense
Design isn’t bolted on later. We map the real customer path — where they get stuck, what they’re trying to finish — so the UI reflects a decision, not a template screen.
Most builds plug into systems you already run: CRM for accounts, billing for payment state, support for ticket history. The customer surface shows live data instead of becoming another thing someone syncs by hand.
Where it helps, we pair the product with n8n behind it — status changes, notifications, follow-ups — so your team isn’t triggering every step after a customer clicks.
Illustrative pilot · not a named client
Customers emailed support to check order status, reschedule, or download an invoice — three request types that ate a chunk of the week. We shipped a self-serve account portal for all three, live from their order and billing systems. Tickets for those three types dropped to near zero in the first month.
This sounds like you if
- Customers email you for things a portal should handle
- You’re running bookings, approvals, or status updates by hand that customers could do themselves
- An MVP got built once and never made it past a prototype
- Support hours go to the same “where’s my X?” question
- You want something customers use — not a feature announcement nobody opens
- Your customer-facing tool still feels like an admin panel with a different logo
What you get
- Fixed-price proposal for a first shippable version
- UI/UX and engineering from the same team
- Testing on your real data and edge cases before launch
- Full source and infrastructure access on delivery
- A support window after launch — optional ongoing feature work
- A clear call on what’s needed for launch vs what can wait
Questions about customer software
Yes, when it makes sense. In scoping we’ll say if extending what exists is faster than a rebuild — we don’t default to a rewrite for our convenience.
We can set it up and hand over full access, or work inside what you already run. Either way, you’re not dependent on us to keep the lights on.
Expected. We ship a first version fast, then scope additions as a follow-on with their own price and timeline — instead of guessing everything up front.
Proper auth from day one — email/password, SSO, or magic links — wired to your existing customer records, not a second disconnected identity system.
Default is Svelte + Supabase for speed to a production surface. If your team already has a stack, we build against that so you can maintain it after handoff.
Yes. Source, deploy access, and docs at handoff — same ownership model as our workflow and skill builds.
Want this scoped for your stack?
Fixed-price proposal after a short discovery call — no open-ended retainers to start.