Four months, fourteen retros

The first commit to RallyPoint landed on May 4th. It was a marketing page and a question: could a visual page builder carry the whole product, or was it going to be a real codebase? By the end of May the question had answered itself, the page builder was a design playground, and we were writing the first of what turned out to be fourteen retrospectives.

We write a retro at the end of every arc of work. Not on a calendar. When a thing is finished enough to look back at. They're honest documents: what we built, what went well, what was hard, what changes. This post is a retro of the retros. Four months, from an empty repository to being able to handle real money with confidence.

May: deciding what this is

The first three retros are about tooling and plumbing, which is the honest shape of a first month. Where the marketing site lives. How environments and deployments work. Getting sign-in right, all the way through the round trip. The one that mattered most had no code in it at all: a long conversation about how design and engineering would work together, written down so we'd stop relitigating it. It started the policy of committing and moving forward with diligence, but being willing to revisit when there is evidence that the wrong decision was made.

The lesson from May, in one line from the retro: scoping together before building keeps the effort shippable. We've never stopped doing that.

June: the foundation, and the first visitor

June was the database schema, then everything that makes a schema real: deployment across three environments, shared authentication between the public site and the app, a public API with documentation, continuous integration that actually gates. The infrastructure retro counted three weeks, sixty-four commits, and eleven architecture decision records. Most of those decisions have held.

The first release tag is dated June 24th. We've cut fifty-six since.

June also produced the model of time that everything else sits on. Time at a convention isn't measured in days; it's measured in timespans, labeled ranges that can cross midnight, some for attendees and some for organizers. Related, no one wants to have to handle clicking numerous datetime boxes each with a datepicker, which is why we implemented the creation of these ranges as click and drag.

Every step of the way we are trying to make the experience as easy as possible, for organizers and attendees.

July: a convention on paper

July's retro has our favorite phrase in it: "convention on paper." By the middle of the month an organizer could run a real convention's paperwork end to end without any money moving. Badge types, registration, a roster with check-in. Volunteers with shifts. Sponsors and exhibitors applying and being answered. Community-submitted events with organizer approval. A schedule with rooms and hosts and waitlists.

This is not to say that everything was perfectly feature complete. There was still plenty of work to be done. But the core fundamentals were there. People could click, edit, and share feedback.

Underneath it though, quietly, the cart and the ledger were being generalized: everything you can acquire is a line item in one transaction flow, whether it costs money or not. That decision looked like over-engineering in July. In August it meant payments landed on a system that already knew how to keep books.

And on July 17th, we released Show Time: the moment a convention site turns into the convention app that sits in every attendee's pocket, with the schedule, the badge, and the alerts tuned to what the attendee needs to know right now. My Schedule stops being a list of shifts, events being attended, or hosting responsibilities. It becomes "What am I doing next? Where do I need to be?" It is still the part of every demo where people's eyes change.

August: the money month

August was payments, and payments turn out to be less a feature than a change of character. Before money, a bug was an annoyance. After money, a bug is somebody's forty dollars, and possibly somebody's trust. So the month was spent less on the checkout itself than on everything that has to be true around it: that the total on screen is the total on the card, that tax is handled the way a treasurer would want it handled, that a receipt arrives, that a refund is possible and honest about its fee, that the books an accountant reads reconcile to the cent. We had the whole API reviewed for security and fixed what it found. We made email actually arrive, which sounds small until it's the receipt for a badge.

The biggest decision of the month was about who the merchant is. The answer is the convention: every convention connects its own payment account, the charge is theirs, and RallyPoint takes a fee from the organizer and never holds anyone's money. It reversed a direction we'd held for two days, it deleted a frightening amount of scope, and it's been the right call every day since.

The month ended with a leadership demo for a convention we'd very much like to run on this, and a surprise partner in the room. The features people loved were the con-day ones. The questions were about money. The two money questions became the two features that shipped this week.

September: live

Self-serve refunds and discount codes went to production on September 2nd, seventy-two hours after they were asked for. That number is the thing we're proudest of from the whole month, and not because of the speed. It's that the two features had been designed on paper, with their rules closed, before a line of them existed, so building them was mostly typing. The same day, reservations learned to expire so a fast sale stays fair, and organizers got a way to cap how many badges one account can buy. There's a public roadmap now too: three lanes and no dates, because we've learned that things move between lanes the moment real conventions get their hands on them.

What fourteen retros taught us

Design before code, on paper, with the rules closed. Every feature that went well had its rules written down before the first line. Every one that went badly had a rule we'd left for later.

Separate QA catches what the builder's tests can't. Our test suite is large and it passes. It also, three times this month, pinned a bug in place because the person who wrote the test was the person who wrote the bug. We make sure that there is a separate review of all code, with human eyes on all new features and changes. Preferably the review happens in the morning with fresh eyes and a fresh cup of coffee.

Same-day fixes can be reliably fixed same-day. When a first-time user found five issues on a Friday night, they were fixed before bed. When a review found five issues on a Wednesday morning, they were in production by one. Speed isn't the point; not letting a known problem age is, with tests in place to keep them from manifesting again. The time spent on infrastructure early, which could seem like a waste of a month, gives the reliability to move later with much more speed.

Write the retro. We almost stopped. Maturing teams grow out of the formalism, the thinking went. What we found instead is that the small corrections had gone continuous, every work session ends with notes, but the long look back still needs a document, or the arc disappears into the commit log.

The numbers, for people who like numbers

Over nine hundred commits. Fifty-six release tags. Nearly three hundred changelog entries. Nineteen architecture decision records. Nearly six hundred API test cases and well over a hundred end-to-end tests that run on a fresh database before every push. Zero server errors at five hundred concurrent users in the load test. One payment account that went live this week.

The first real badge sale hasn't happened yet. That's the next retro.