Starter School is in its third and final phase. This last three month sprint is the culmination of a grand experiment to see if we can learn how to build and ship a successful product in nine months. More importantly, the folks at Starter School are trying to teach us a successful process for building products, since our current ones aren’t guaranteed to succeed.

While trying to find what process works best for me, I’ve been building CapTracker, a tool to help entrepreneurs focus more on building their product, and less on managing their capitalization. It’s essentially a cap-table-as-a-service, and aims to simplify the process of founders managing their company’s equity.

The idea came from my dad, a lawyer by trade, who deals with the troubles of early stage companies on a daily basis. It’s been a challenge for me to build an app to serve needs that I’ve never had, but really studying the problem and attempting to find a repeatable process has helped me a ton.


The logical first step in the process of building a product. This is where you break down the problem you are trying to solve and create a model of the different pieces of the app. For CapTracker, we broke it down to this: There is a company that issues stock, people to issue that stock to, and an issuance of stock to be tracked. This is a sort of lightweight domain model, which will become more in depth later in the process.


The lower fidelity, the better. Quick sketches get interface ideas out of your head and can help you nail down what the structure of the screen should look like. It also helps to communicate with others working on the product. My dad sent me this sketch for the dashboard screen to give me an idea of what he wanted:


Having this sketch keeps me as the designer/developer from taking shots in the dark at what elements are critical to the design.


Now that I have an idea how the screen should look structurally, I can use HTML and CSS to make a more detailed mockup of what the interface should look like. One point that has been hammered home in our design classes is to not use “lorem ipsum” for populating our mockups with data. Using realistic data is much more valuable because it mimics exactly how the app will look in production.

Don’t code!

This has been the hardest part for me to adopt, but it’s one of the most important. It takes discipline and restraint, but waiting to write the backend for a screen can save you from many headaches in the future. Iterate on the first few steps until the screen feels right.

Domain Model

Thinking about the backend of the app starts with the domain model. This is where you break down the model you thought of in the beginning of the process into parts that will make up the code for the app.

With CapTracker, this meant taking something like a person, and thinking about it terms of it’s different types. Legally, a person can be an individual investor, or an “entity”, such as a VC firm. This is a distinction that needs to be made, and the domain model allows you to think about the behaviour and relationships of the models in your app before you write any code.

The fun part

Now I can start writing some real code, and I have a much clearer direction for what I need to build. It’s easy to lose sight of the scope of a feature if you start with writing code. I’ve made much more progress using these steps for every new feature than I did when I started building CapTracker.