As a co-founder and engineer, it’s a joy to share what I’ve learned about building products with my co-founder, customers, and industry leaders. Even more fulfilling is when I learn from other people too, keeping me humbled by how much I have yet to know.

So what I’m talking about today—the way we build features at Standard Form—is what we think works for us, but I’m always looking for better ways of working. Rewriting this essay three years down will look completely different.

As my first essay in this column, first let me share where I get my context.

I spent the past 5 years working in regulated industries, first as an IBM developer working with insurance companies and then as an engineer building ledger systems in a digital bank. Both times I've seen how risk aversion, and the strategy made thereof, makes building software like wading through deep water, without much margin for risk tolerance.

I was also lucky enough to be reading forward-looking technical articles, especially the early Palantir blogs, back when the company was still private and its product elusive. One article stuck in my memory, which describes how they managed to continuously deploy software in air-gapped, classified networks like a submarine. So, much of what I'm going to say here is based on these two contexts.

Now, Liz and I are building Standard Form, software for healthcare providers to create and manage healthcare forms.

Building features at Standard Form boils down to three concepts: outcomes first, demo frequently, and build the right foundation.

Outcomes first

Since we’re serving front-line use cases, Standard Form has to serve credible outcomes, down to the user flow and buttons we lay out. These outcomes must be rooted in reality on the ground or approximated to it. We can then prune outcomes that don’t matter, but more importantly abstract away implementation detail that avoids shiny objects from influencing priorities. When we were building a demo for physicians, the outcome was pretty simple: to see if they could complete the consenting process in Standard Form. So anything that sounds important, like building consent completion status, isn’t a ‘now’ problem that achieves that outcome.

Of course, that outcome is too narrow when we’re building an entire form management software. Another contention is that without real customer validation—hospitals paying for our product—we can conjure up all sorts of seemingly credible outcomes all the time, and make them our north star. As early-stage founders, it’s unavoidable that we have to frequently switch from a micro to a macro perspective, and we have to accept that we can be wrong about which outcome is credible.

What we can control is how fast we can get to that realization without feeling we’ve wasted too much of our time and effort. This brings us to the second point.

Demo frequently

We need to communicate the value of a feature by demoing frequently, even internally. I found that the prospect of a demo focuses the effort on ensuring that we can discuss whether what we built matters and get high-quality feedback. Here, I define demo quite loosely: A wireframe with paper and pen can also be a demo, as it can still serve to communicate the value of a feature. The more frequent the demo, the faster we can change in the right direction.

This point is actually inspired by a book gifted by a friend (thanks, Harvin!), which describes in detail how the first iPhone keyboard was built, told by the creator himself. It was quite brutal, in that a demo is done once every couple of days. They even have a hierarchy where a good demo would then be given to more senior people, all the way up to Steve Jobs himself. The beauty of this process is that high-bandwidth discussions can happen in front of a tangible object, as opposed to a “think of a white cat” moment where my cat is different from yours, and time is wasted on just explaining what my cat looks like.

As early-stage founders, it’s unavoidable that we have to frequently switch from a micro to a macro perspective, and we have to accept that we can be wrong about which outcome is credible.

Another good side effect is that we’re not easily satisfied by work that is ‘finished’, but rather are satisfied with work that is ‘valuable’. It frees us from being too static in our approach, like how we spent a 3-day sprint building a totally unrelated mini-app in an attempt to extend our personal runway, giving us more time to iterate in the long run.

But building for healthcare providers, unlike other industries, limits our ability to iterate in front of real patients, as patient harm can be fatal, both to them and to Standard Form.

Build the right foundation

It pays to allocate engineering resources to technology that supports our product reliability, now and in the future. For us, we think that permissions-based access, like making a subset of patients visible to physicians, is table stakes for hospitals. There’s also the form-building engine that we built in-house for converting paper-based forms into a format that’s understandable and deployable inside Standard Form.

Of course, we need to build business logic that is also valuable to healthcare providers, like supporting consent for all kinds of surgical procedures, but this is something that we can build together with them, catering to their specific needs.

The cost of not doing this for healthcare customers can be high, as they have significantly more intricate processes and departments than a typical 2,000-employee company. For instance, expecting them to work with software that does not serve multi-department touchpoints is unrealistic.

Conclusion

We’ve embedded some high-level guiding principles that let us ship features quickly, but within the bounds of reliability standards expected in a high-stakes patient interaction. Within those principles is a bias towards outcomes that matter to customers and demos that communicate value clearly.

We hope you enjoyed this tour on how we build features for Standard Form. If you want to learn more, we encourage you to read our thoughts around informed consent, where we have done quite in-depth research. Keep an eye on more technical content as we explain what technology we use in Standard Form.

At Standard Form, we help healthcare teams modernize their informed consent workflows without disruption — supporting better care, clearer communication, and stronger compliance from day one.