Rally

The Situation

Rally is a SaaS product I conceived, designed, and built on my own. There was no client brief and no external pressure to ship. The prompt was something I noticed watching content creators online: a specific kind of generosity that lives inside their platforms, built into what they do rather than bolted on as charity. I wanted to make something that runs on that same logic, a platform where giving back is the mechanism, not an afterthought.

What Was in the Way

The hardest part of building something with no external brief is that the problem itself has to be found, not handed to you. Most giving platforms put the burden on the individual: someone has to decide to give, go somewhere to do it, and repeat that act every time. That friction means generosity stays episodic. People mean well and still do nothing, because the path is long enough that life gets in the way.

The deeper problem is trust and legibility. A platform that moves money between strangers lives or dies on whether people believe it will do what it says. Without that, the pool never grows large enough to matter to anyone on either side. Building that trust into the product, not just into the marketing around it, meant every decision about how the flow works, how Stripe connects, how a member sees what has happened with their contribution, had to be made deliberately. There was no design team to pressure-test those decisions. I had to hold both the skeptical user and the hopeful one in mind at the same time, and write the logic that would satisfy both.

The personal constraint was time. This was self-funded and self-directed, built alongside everything else. Scope had to stay disciplined or the product would never reach a state worth pushing.

What I Did

I started with the core mechanism: what happens when someone joins, what triggers a payout, and how those two events are connected in a way that scales. The answer I landed on is that the platform’s output is a direct function of its membership. More people joining means more people helped. That is not a metaphor; it is how the math works. I designed the product around making that relationship visible to every member, so the incentive to grow the community is built into the experience of using it.

For payments I used Stripe. It handles the compliance and the movement of money, which meant I could focus design attention on the parts that actually differentiate the product: the logic of who gets helped, when, and how that is shown to the people who made it possible.

I used Claude Code to accelerate development. The decision to use it was deliberate: I was writing the product as a solo developer, and the goal was to reach a testable, shippable state without cutting corners on the parts that matter. That meant using the tool where it saved time on implementation and staying close to the decisions that the tool cannot make, the ones about what the product should feel like and what it should refuse to do.

What I rejected was complexity for its own sake. Early thinking included more elaborate routing logic and more member-facing controls. I cut both. The platform should feel inevitable to use, not configurable.

What Happened

Rally is not live yet. Testing is the next step, and I am close enough to that to say it is nearly complete rather than ongoing. What I have is a working product: the payment layer is integrated, the core mechanism runs, and the member-facing experience reflects the decisions made in design. The gap between now and public launch is testing and the push to my own platform, where I will be the first person to use it in the way I designed it to be used.

That matters because I am not releasing something I built for someone else and then stepped back from. I am going to be inside it, which is its own kind of accountability. If it does not work the way it should, I will feel that before anyone else does.

What I Took From It

Building a product with no client changes what discipline means. The pressure to finish is internal, which makes it easier to rationalise delay and harder to know when something is good enough. What I learned is that the decision to cut scope, the one I made around the routing logic and the member controls, was the right call to make early and would have been much harder to make later. Complexity that feels like richness in the design phase becomes weight in the build phase. Ship the mechanism. See if it works. The rest can follow.