Three builds taken apart — including the part of each that was actually hard.
First, what these are. All three are applications we built ourselves to prove the stack across the kinds of systems people actually commission. They are not client engagements, and we are not going to present them as though they were.
That turns out to be the useful thing about them. Client work is the work you are least able to show: the interesting parts are the ones under an NDA, and a logo on a page proves nothing about whether the software works. These we can open all the way up — you can read how each was assembled, and then go and press the buttons on the running site yourself.
Each one below covers the same four things: what it is, the part that was genuinely hard, what is actually running, and what the equivalent would look like on a project of yours.
A site where the writing leads, readers can become paying members, and the mailing list belongs to the publisher rather than to a platform. Posts with categories, tags, bylines and scheduled publishing; three membership tiers; a newsletter; threaded comments underneath.
Not the blog. It was that a paid tier has to genuinely control something. A seven-day trial has to end on its own; an upgrade mid-month has to charge the right amount; a failed card has to downgrade access without deleting the account; and a reader who cancels has to keep what they already paid for until the period runs out. Subscription billing is easy to demonstrate and hard to get right on the edges, and the edges are where the support email comes from.
On your project. This is the shape of anything that sells recurring access — a trade publication, a training library, a members' area bolted onto a site that already exists, a directory behind a paywall. The billing and entitlement half is the half that gets underestimated, and it is the half we would build first.
Open the running site →Quill is an original build inspired by Ghost. It is not affiliated with Ghost.
Topic boards where people post links and text, vote each other's posts up or down, and argue in nested comment trees. What rises to the top is decided by votes and time, not by an editor.
Ranking and moderation, which are the two things a community lives or dies on. A feed sorted by raw score shows you last year's best post forever, so the score has to decay with time in a way that feels right — new things get a chance, good things persist, and nothing sits on the front page for a week. Then moderators need real power over their own board — lock, pin, remove, ban, work a report queue — without being handed the keys to the whole site. Getting that permission boundary right is a genuine design problem, not a checkbox.
On your project. Most systems that need this are not trying to be Reddit. They are a customer forum, an internal knowledge board, a members' network, a support community attached to a product. The ranking matters less there; the permission model matters more, because the people moderating are usually staff who must not be administrators.
Open the running site →Hearth is an original build inspired by Reddit. It is not affiliated with Reddit.
A direct-to-consumer shop built around big product photography and star ratings: catalog, product pages, a cart that works for guests as well as members, a full checkout, and customer reviews. Payments run in sandbox mode, so nothing is ever charged.
Checkout. Everything before it is presentation; checkout is where a store actually breaks. Address, then shipping rules, then payment, in an order that has to survive a customer going backwards, a card declining, a coupon that should not apply, and two people buying the last unit at the same moment. An order has to exist in a recoverable state at every one of those points — an order record created before a payment confirms, and not created twice when the customer hits the button again.
On your project. Commerce work usually reaches us as an existing store that needs something specific — a shipping carrier connected, a tax rule corrected, stock reconciled against another system, a checkout step that loses people. This build is the reason we can say the whole path is familiar rather than only the part you are pointing at.
Open the running site →Roam is an original build inspired by Allbirds. It is not affiliated with Allbirds.
They do not prove we have built your application before. Almost nobody has, and a supplier who claims otherwise is usually describing a different project that happened to share a word with yours.
What they do prove is narrower and more useful: the parts your project is made of — accounts and roles, recurring billing, permissions that hold under pressure, a checkout, search, an admin somebody can actually operate — are parts we have built, shipped and left running, and you can verify that yourself in about five minutes rather than taking our word for it.
There are fifteen more you can open covering booking, ticketing, marketplaces, accounting, auctions, learning, help desks and the rest. How we build explains why a build like one of these takes the time it does, and contract work covers the more common case, where the system already exists and needs to do something new.
Tell us what you are trying to build or fix and you will get a straight answer on whether we are the right people for it.