Loading
Loading
Work
These are products built in-house to run our own businesses, not client work — there are no clients yet, and inventing some would make every other claim on this site worthless. They are here because they are the real thing, and because you can open any of them with us and read the part you doubt.
Internal product · pre-launch
A booking and scheduling platform: businesses publish their availability, customers book and pay, and the money settles to the business rather than to us.
Evidence for: SaaS & Platform Build
Multi-tenant from the schema up. Each business is an organisation with its own services, resources, staff, availability rules, blocked periods, and public booking page. Customers sign in with a four-digit emailed code rather than a password, and the session is revalidated against the database on every server render rather than trusted from a signed token.
Payments run on Stripe Connect Express, which means each business is the settlement merchant for its own bookings and we are never in the flow of funds. Charges are created with `on_behalf_of` so the customer's statement shows the business they booked with, and the connected account's readiness to take money is written only by Stripe's own `account.updated` webhook — never asserted by the client.
The interface ships in five languages with real translations rather than machine-filled placeholders. Four of the five are complete apart from twenty-six keys on the dashboard overview screen, which still falls back to English — a real gap, stated here rather than discovered.
The part that is hard
The payment state machine claims its transitions with a conditional update guarded on the state it is moving *from*, so the Stripe webhook and the booking's own status endpoint can race — as they routinely do — and the confirmation email still fires exactly once. Card payments only, deliberately: SEPA and ACH fire the completion event before the money has actually settled, which would mark a booking paid against funds that can still fail. That decision is written down in the code with its reasoning, next to the refund calls that carry idempotency keys so a dropped response cannot refund twice.
In development · schema not yet migrated
An escrow marketplace for freelance work: a client funds a project up front, the money is held, and it is released to the freelancer milestone by milestone.
Evidence for: SaaS & Platform Build
The hard part of escrow is not holding money, it is releasing it exactly once. A milestone release claims the milestone with a conditional update on its funded state, so two clicks, a double-submitted form, and a retried request all resolve to a single payout rather than to two.
Payouts are deferred rather than failed when the freelancer has not finished Stripe onboarding: the release succeeds, the amount is recorded as owed, and a sweep pays it the moment their account becomes eligible. Six Stripe event types are handled including the full dispute lifecycle, and every incoming event is recorded in a dedupe table so a replayed webhook is a no-op.
Authentication is split across the Next.js runtime boundary — providers in an Edge-safe config, the database-touching callback isolated so it never gets bundled into middleware. It is an unglamorous problem that breaks a lot of Next.js applications in production, and it is solved here rather than worked around.
The part that is hard
The session's user id is pinned to the application's own user record rather than to the OAuth provider's account id. That sounds like a detail until somebody signs in with a second provider and the system treats them as a new person, or until a provider recycles an identifier — at which point it is a data-integrity incident in a product that moves money.
Built · not yet deployed
The site you are reading, which is the most honest reference build available for the website tier — you are already inside it and can check every claim on this page from your own browser.
Evidence for: Website & Landing Page
Statically rendered, self-hosted fonts, and no third-party scripts of any kind. There is no cookie banner because there is nothing to consent to: no analytics, no tracking pixels, no embedded video, and not one runtime request to a domain that is not this one.
Every text colour in the palette is documented with its measured contrast ratio against both surfaces it can appear on, and the lowest of them is 5.59:1 against a 4.5:1 requirement. The one decorative colour that would fail as text is labelled in the stylesheet as never to be used for text.
The whole site is one interactive element — the enquiry form below — and everything else is server-rendered markup. That is the reason it loads the way it does, and it is a choice available to most marketing sites that do not take it.
The part that is hard
Accessibility here is measured rather than asserted. There is an automated pass over every route that fails the build on any WCAG 2.1 AA violation, and the docblock above it says out loud that automated testing catches roughly a third of the standard and names the criteria it cannot check. A tool that reports zero is evidence; a tool that reports zero and tells you what it did not look at is a different kind of claim.
Across everything
These come from running the suites, not from a badge. One test currently fails and five are skipped, which is why the figure is written the way it is — a repository claiming a clean sweep is either very small or not telling you something. On the call we can run them in front of you.
Next step
The first call is a screen-share of whichever of these is closest to what you need — the payment code, the schema, the tests, the thing you think we are overstating. Prices are on the pricing page, in full, before you ask.
We reply within one business day.