10 Lessons From Building More Than 100 Software Projects

Some were fairly straightforward. Some went on to be really successful. Others changed direction more times than anyone expected.

Having now delivered more than 100 projects, I keep seeing the same things crop up. The technology changes, but the way people and businesses work tends not to.

Here are ten things I've learned along the way.

1. The real problem is rarely the one first described

When a client tells me they need an app, my first job is to work out what is actually getting in the way. Most of the time, the app is only part of it. The real issue is usually a process that no longer works properly.

• Staff enter the same information several times.
• Important data is trapped in spreadsheets (or worse PDF's)
• Email has become an unofficial workflow system.
• Nobody has a clear view of performance

Software might be the answer, but I would never start there. I would start by looking at the process, where it is slowing people down and what genuinely needs to change.

2. The most valuable software is often the boring stuff

Developers naturally get excited about new tech, and I am no different. However, in my experience, most clients are more interested in whether it saves their team time and makes the day-to-day work easier.

Some of the most useful projects I've delivered have been automated reports, workflows, stock tracking, customer portals and systems that keep data in sync. None of these sound particularly exciting, but it can save a business hundreds of hours each year. Not every bit of software needs a UI or brand to work, some just tick in the background.

3. Data quality beats features (IMPORTANT!)

I put this third because you've already built the system and likely like me failed the first two checks, plus this is usually quite difficult to check before starting a project.

Conversations often start with mobile apps, dashboards, AI and integrations. One of the first things I want to know is such simpler; can we trust the data underneath it all?

Duplicate customers, incorrect stock figures and inconsistent addresses will cause problems no matter how good the new system works. There is little point adding more features if the information behind them cannot be trusted.

I would rather sort the data first and build on something solid.

4. Users want less

It is easy to respond to a problem by adding another feature. What users normally want is fewer clicks, less typing, less training and a quicker way to get the job done.

The best features I've built have removed work rather than adding to it. Keeping something simple does not mean you have lacked ambition.

The customers I've worked with have been instrumental in helping me understand this. They know how I work and aren't afraid to challenge me when I've over engineered a solution. As someone who has always been highly technical, I've often rolled my eyes when people describe users as being "bad with technology". Then Ironically, some of the feedback I'm most proud of is when customers praise how easy a system is to use, when months earlier I have grumbled about simplifying it in the first place.

5. Every business thinks it's unique

I hear "we're different" a lot. Sometimes that is absolutely true. more often, most of the way they work is identical to other businesses in the same industries.

Getting the common parts right gives you a system that is stable and easier to maintain. The value comes from understanding where your business really is different, rather than treating every part of it as a special case.

If most businesses work a certain way when it comes to a piece of tech then maybes most others should start there, then see where they can be different.

6. Integration can matter more than the software itself

Most websites and applications do not work on their own anymore. They need to connect with Microsoft 365, CRM's, accounting software, ERP platforms, payment providers and job management software.

Building the screens is often the straightforward part. A lot of the real work is making sure information moves between systems securely and reliably, and that people can understand what happens when something goes wrong.

7. Technical debt often begins before development

Technical debt often gets blamed on rushed code, or now AI generated code. From what I've seen, it can start before anyone writes a line. Unclear requirements, conflicting rules, vague terminology and changing priorities all get carried into the build.

If the business has not made a decision, the software still has to make an assumption. Those assumptions quickly become part of the foundations and can be expensive to change later.

I've worked with clients rebuilding entire systems because we made a shortsighted mistake that becomes too complicated to build around and sometimes a full migration is the cheapest (expensive still) way out

8. The best clients don't arrive with every answer

The best clients I've worked with know their business, the problems they are facing and what they want to improve. They do not pretend to already know exactly what the technical answer should be.

Things get harder when a particular platform or solution is decided before the problem has been properly explored. The best results come when the client brings their knowledge of the business and we work out the right technical approach together.

9. AI has accelerated development, not replaced judgement

AI has made development much quicker. Work that used to take days can sometimes be drawn down to hours. What it has not done is removed the need to ask the right questions.

• What should we build?
• Which problems are we actually solving?
• How should the systems fit together
• Which data can be trusted?

AI can help with code, designs and documentation, and I use it where is makes sense. It still cannot help understand the full context of a business or take responsibility for the decisions being made. It helps us move faster, but judgement still matters.

10. Software only created value when people use it

This is probably the biggest lesson for me, and the biggest concern when finishing a project. A perfect system that nobody uses is worthless. A fairly average system that the whole team gets behind can completely change how the business works.

That is why I think about training, adoptions and ease of use early on, not once the build is finished. The technology is only one part of it. The value comes when people trust the system and use it properly.

Frameworks, languages and platforms will keep changing. Being able to understand people, processes and the actual problem is what continues to matter.

Conclusion

If you've made it this far, you'll have realised this article is dangerously close to becoming one of those "Top 10 Lessons" posts that every developer secretly rolls their eyes at.

In my defence, my marketing partner has been encouraging me for years to write more about the projects, successes, failures and lessons I've accumulated throughout my career. I've always found it easier to build things than write about them, but eventually I realised there might actually be value in sharing some of that experience.

I chose this format because it gave me a starting point. Each of these lessons could easily be an article of its own. Behind every point are real projects, difficult conversations, poor assumptions, unexpected successes, costly mistakes and occasionally a few moments where things worked out far better than I ever expected. Over the coming months, I plan to revisit each lesson individually and share some of the stories, challenges and insights that shaped them.

Writing this has also been a useful exercise in reflection. As I finish a large SaaS platform that has consumed years of my time, I'm finding myself revisiting many of these ideas. For most of my career, the businesses I built software for carried the commercial risk. My job was to understand the problem, build the solution and help them succeed.

This time it's different.

The responsibility for whether the product succeeds or fails sits much closer to home. That has forced me to think more deeply about adoption, simplicity, positioning, customer feedback and all of the things that exist beyond the codebase itself.

Looking back, some of the projects I poured the most effort into quietly disappeared. Others that I almost considered routine went on to become products that users still rely on years later. Experience has taught me that effort alone doesn't determine success. Understanding does.