Lessons for people who build software

I was the first employee in a software business that was founded by someone who had never written a line of code. I was exposed to many mistakes and learned valuable lessons for Founders and in-house developers to consider.

Go on a diet.

You are going to build things that people don't use. Delete the code if you don't use it. Remove features that aren't right, or be prepared to keep adding tweaks or hearing about minor issues repeatedly.

Saying 'No' doesn't make you look bad.

More internal tech projects fail because too many features got added in than because something critical got missed. Less, but better.

Invest in Product Management.

This is a must-have role in software vendors and, crucially for developers and Founders, it creates a dynamic for challenging both ways.

Create and maintain a features list.

You want to assess your roadmap or backlog against your current features list and the features you're missing. When you leave a feature out, you can flag it as 'not doing' so everyone knows you missed it on purpose rather than thinking it was an oversight. (documentation)

You can't build everything that your client asks for.

This is even more true if you are the only client for your software. You need a time-based filter between requests and development and that product management role.

Strategy is often about what you don't do.

Reposition the use of third-party software as reducing your risk for features that don't deliver your vision or a competitive advantage. 'We bought that off the shelf because CRM is an established category, and our needs are basic.'

Take advantage of homogenous software platforms.

Xero, ApprovalMax, Shopify, Zapier, Make, HubSpot. Gifts from the software gods. Why deviate when someone dominates a category and makes it affordable, flexible and cost-effective?

Use a help desk/ticket system for internal issues.

When we put in Zendesk and upgraded our forms to ask what feature issues related to, whether they were mobile app or web app related etc., it got way easier to analyse how the system was performing. Weird that? Yet very few internal teams set up so much as a form for taking in requests or logging issues.

Visualise your system architecture.

People can't look at your code and validate that you know your stuff. Drawing out some simple workflows in Miro helps you to understand what you've built - you can even do it before you build stuff too...

Assess how every feature you build will deliver part of your strategic vision. If you're going after features money can't buy, ensure they're the only ones you touch.

When it comes to deciding on non-vision-related solutions, I recommend that you:

First, review and consider off-the-shelf software.

Second, consider building it using low code in Airtable, Retool or integrating with API services like Flatfile for CSV imports.

Third, build it full stack.

- Thanks, Oliver