Swift IdeasSaaS & web platforms
Platforms with the hard parts built first.
Sign-in, keeping each customer's data separate, billing and permissions decide whether a platform survives its first hundred customers. We build those first, with the separation enforced by the database itself, and test them before anything else. Dashboards, portals and admin screens go on top of a spine that already holds.
What clients arrive with
- Our MVP has one database and no reliable way to say which customer owns which row.
- Billing is a spreadsheet and a payment link.
- Clients, staff and contractors need to see different things in the same app.
- Contracts get signed over email and nobody is sure which version was approved.
- Every new feature breaks something, and there are no tests to tell us what.
What you get
- Tenancy and permissions in the database
- Row-level security policies scoped per organisation or per workspace, plus tests that fail if a query for a tenant's admin screens stops filtering by that tenant.
- Authentication done properly
- Magic links or OAuth with PKCE, state and nonce checks, and a verified identity token. Provider tokens stay on the server; the browser holds only an opaque session cookie.
- Billing and entitlements
- Stripe Checkout and webhooks for trials, upgrades, failed payments and cancellations, with RevenueCat alongside when there is a mobile app. Paid actions re-check the subscription on the server.
- Dashboards and portals by role
- Role-aware routes for owners, managers, buyers and contractors. Empty and error states are real states: a production dashboard never fills a failed response with sample data.
- Workflows as state machines
- Signing, approval and fulfilment flows modelled as explicit states with webhook-driven transitions. In the SwiftGxP course player, the next module opens only after the previous one is complete or its quiz is passed.
- Security hardening
- Content Security Policy with per-request nonces, third-party keys encrypted at rest with AES-256-GCM, and an audit log for the actions that matter.
- Jobs, email and a launch gate
- Scheduled jobs on Vercel Cron, transactional email through Resend, and a launch check script that must pass before production is switched on.
How the work runs
Model the tenants
Who owns what, who sees what, and who pays. We write the schema and the row-level security policies before we design a single screen.
Build the spine
Auth, tenancy, billing webhooks and the audit log, deployed to a preview URL in the first week so every later feature lands on working foundations.
Build the surfaces
Dashboards, portals and admin, each with a Playwright journey per role that signs in and completes the job that role exists to do.
Pass the launch gate
A scripted launch check covers environment, callbacks, webhooks and policies. Production opens when it passes, not when the calendar says so.
How engagements start
- Prototype to production in 4–8 weeks for a focused first release: one tenant model, one billing plan, the core workflow.
- Fixed-scope phases after that, each with its own launch gate.
- Retained iteration for teams who want a senior pair of hands on the platform month to month.
- Existing codebases welcome: we start by reading it and putting tests around what already works.
Built with
Where each number comes from
Each figure names where it comes from.
- encryption for stored customer API keys, bound to the workspace
- AES-256-GCM
- Source: Holdrate: the product's own technical documentation
- quiz pass mark that gates the next module in the SwiftGxP training platform
- 80%
- Source: SwiftGxP: the pass mark set in the training platform's code
- test files covering the site and the training platform
- 38
- Source: SwiftGxP: counted in the project's test suite. 24 files are named for the task they prove
The work behind it
Questions, answered
Something else on your mind? hello@swiftideas.com
Why Supabase rather than our own Postgres?
It gives you Postgres, auth, storage and row-level security in one managed service, which removes weeks of plumbing. It is still Postgres, so the data and schema move with you if you outgrow it.
How do you handle multi-tenancy?
In the database, with row-level security policies scoped to the organisation, and tests that pin every tenant-facing query to its tenant. Application checks sit on top, not instead.
Can you take over a platform someone else built?
Yes. We read the code, map the data model, put tests around the paths that earn money, and only then start changing things.
Do you support single sign-on?
OAuth providers and magic links are standard in our builds. Enterprise SSO depends on your identity provider, so we scope it against your setup during discovery rather than promise it blind.
Where is it hosted, and who owns the accounts?
Your own Vercel and Supabase accounts, in the region you choose, including UK and EU. You own the repo, the data and the billing relationship from day one.
Who actually builds it?
The two founders. We use agent tooling for repetitive implementation, and every change is reviewed and verified in a real browser before it merges.