My first startup taught me this key idea. Now my second is growing 30% every month

On a bronze age path in Peloponnese Greece stands a stone arch bridge dating back as far as 1300 BC.

Designed for chariots and spanning about 20 meters, the bridge’s longevity highlights a wider gap between software and civil engineers. The fundamental question of how you build what you build.

This difference is the basis of one of the most valuable lessons any programmer can learn.

While civil engineers design for durability, following best practices honed through centuries of work, things are completely different for engineers building mobile apps.

They have, at best, a quarter of one century of figuring out best practices.

They operate in environments that emphasize innovation — coming up with things that have no blueprint, that customers may not even know they want.

The real value of code

Because of this, when you build an app or product feature you aren’t designing for the ages. If people don’t ultimately use what you make, the quality of the build won’t matter.

This then is the principle that engineers at startups should never lose sight of: The worth of your code is based on the value your end customer puts on it.

Your priorities should be in the projects that customers value, and if you don’t know this, you absolutely have to get that feedback as soon as possible.

It’s something that for the most part I learned at my first startup, the fashion app Stylekick.

The experience changed how my co-founders and I approached Cover, the insurance app that recently announced its Series B round.

At Stylekick I would think, ‘Ok I can use all this crazy whizzbang technology, but is it solving a real problem for a real person or is it something that engineers are going to spend months working on and no one is going to use?’

We could spend three months building a feature only to release it to a pretty muted customer response. Other times, we’d hack something together in a week or a few days, release it, and users would just love it.

Building for users

What I learned is that the goal is to provide some sort of value to a person. The code is just a means to an end.

A lot of engineers particularly will think of code as inherently valuable and they get wrapped up in the code but the real point is this:

Do something of value for someone else.

Too often startups fall in love with their idea and fail to test it against reality.

The focus should be on building the kernel of the idea, instead of the biggest possible version. Then it’s about getting that kernel out in front of people and getting real feedback.

This real feedback is crucial. A challenge with things like surveys is that a person’s behavior when using something is often different to what they say if they imagine themselves using it.

The actual use of the thing provides more valuable feedback than asking people what they think about something.

From a startup perspective, you’re just trying to get feedback from customers as quickly as possible to know whether you’re on the right track. In this the only metrics are ‘Is this in production?’ and ‘Are people using it?’

Focus on two things

After Stylekick, Cover was accepted into Y Combinator’s Winter 2016 program.

Our experience at Y Combinator hammered home this point. Focus on two things: Write code and talk to users. Build stuff and get feedback.

These are the only things that fundamentally matter. This isn’t something that really gets taught in school, but something you figure out later.

At Y Combinator, we got to see that principle play out in multiple areas very quickly. We would have bi-weekly group meetings and every meeting would have someone talking about a problem their startup faced.

The advice would be to slim the issue down into you doing something every day for the next two weeks and getting feedback on it.

The essence of everything was asking what the smallest version of this was that you can do and then get feedback on that version very quickly.

So say you need 100 sales presentations to get some sort of feedback on a product. How many people do you need to reach out to get 100 sales presentations? How do you get those leads?

By looking at it this way, you break it down into more manageable tasks that you can accomplish daily and you will get the feedback you need.

Putting the theory into practice

At Cover, this strategy has paid dividends. This is where product and engineering really intersect; what do we build and how do we build something quickly to validate or invalidate an idea.

We introduced a feature to give people their insurance quote via SMS as soon as possible after they submit their quote details.

We could have engineered the whole thing and put the price in app, but the SMS feature was something we could put together very quickly, allowing us to get it out, and rapidly get feedback.

The feature proved to make a huge difference and our sales spiked.

Since then we have iterated on the copy by doing phased rollouts. Having learned what information users wanted, we moved to bring the price messaging into the app.

Our approach towards customer feedback has enabled us to focus on building the things they actually value. Cover’s annualized premium already exceeds $8.5 million and is growing 30 percent every month.

Find feedback fast

Without historical precedent, we need to fast-track our way to user feedback of what people want when we build software.

Other non-software engineering disciplines have well-defined practices honed over decades if not centuries of practice. A bridge built quickly to establish if people would use it would be very unlikely to stand for thousands of years.

Startups don’t have a luxury of time to fine-tune what they build.

For the engineers, sure, this fine-tuning can be interesting and fun. There can be a lot of nitpicking about the best way to do this or that.

Yes, some ways of writing code are more maintainable or more scalable than others. That’s all well and good. But in the end, the true benchmark for your code is whether you are doing something for your end customer.

The more time you spend finding that out as quickly as possible, the better.

Anand Dhillon, Co-founder & CTO @ Cover