Why The Best Software Teams Think More Than They Code

AI Has Changed Development. It Hasn't Changed What Matters.

Artificial intelligence has changed software development more in the last few years than perhaps any other technology has in the last two decades. Today it's possible for someone with little or no development experience to describe an idea in plain English and, within minutes, watch a web application begin taking shape.

Login screens appear almost instantly, dashboards populate with sample data and workflows that would once have taken weeks to build suddenly look achievable in a single afternoon. It's genuinely remarkable technology and, unlike many commentators, we don't see that as something to fear. At Elemental we use AI every day because it allows our developers to automate repetitive work, explore technical approaches more quickly and spend less time writing routine code.

What AI has done, however, is expose a misconception that has always existed within software development. Because software is visual, it's very easy to assume that if something looks finished, then it must be almost complete. After all, if users can log in, navigate around the platform and click through a collection of polished screens, surely most of the difficult work has already been done.

After more than twenty years of building custom software, we've learnt that the opposite is usually true.

The software people interact with every day is only the visible outcome of hundreds of decisions that were made long before anyone started writing production code. Those decisions determine how secure the platform will be, whether it can cope with millions of records instead of thousands, how easily new features can be introduced in the future and whether another developer will still understand the application three years from now.

They also determine whether your users quietly enjoy using your platform or slowly become frustrated by workflows that seem perfectly logical during development but don't reflect how people actually behave in the real world.

Those are the conversations that rarely appear in a project demonstration because they're largely invisible. Clients don't see them, users never think about them and they're almost impossible to appreciate simply by looking at a finished interface. Yet they're often the difference between software that continues supporting a business for the next decade and software that needs rebuilding just as it starts gaining traction.
 

A Project That Changed The Conversation

One particular project reminded us of that lesson more clearly than any other.

A few months ago we met the founder of an educational programme that teaches entrepreneurial skills to school children. He'd spent years refining the programme by personally visiting schools, working directly with students and continuously improving the content based on real-world experience.

The programme had been incredibly successful and the feedback from schools was consistently positive. The challenge wasn't proving that the concept worked. The challenge was that one person could only visit so many schools, which meant the impact of the programme would always be limited by the founder's time. Like many successful businesses, he'd reached the point where technology wasn't simply a nice-to-have. It had become the only realistic way to scale.

Excited by the rapid progress AI was making, the founder partnered with someone who had started building applications using AI-powered development platforms. Over the next three to six months they produced what appeared to be an impressive web application consisting of more than forty individual screens. When we were eventually invited to review the project, the founder confidently explained that the platform was around eighty percent complete and that he was looking for an experienced development team to help him finish the remaining work before launch.

From his perspective, it was a perfectly reasonable conclusion. The application looked professional, the branding was consistent and many of the screens appeared to function exactly as expected. If you're not involved in software development every day, it's difficult to know what lies beneath the surface, so it's only natural to judge the platform by what you can actually see.

Looking Beneath The Surface

We began the review as we normally would, suggesting a handful of improvements to the user experience and pointing out areas where the workflow could be simplified. Two weeks later we were shown another demonstration. The requested changes had been implemented, but new issues had appeared elsewhere. Those were discussed, another round of changes followed and, once again, different parts of the platform had become problematic.

After watching this cycle repeat itself several times, it became clear that we weren't polishing a platform that was approaching completion. We were trying to stabilise software that had never really been designed properly in the first place.

The founder eventually asked us to take over the project and prepare it for launch. Before committing to anything, we spent time reviewing both the application and the underlying codebase. Interestingly, the biggest concerns weren't immediately technical. They started with the way the platform had been conceived. Only one user journey had really been thought through, and even that journey wasn't complete.

Several other user types still needed to be designed, each with their own permissions, workflows and functionality, yet none of those requirements had been properly explored. There was no documented Discovery process, no technical specification, no database design, no user journey mapping and no clear plan explaining how the platform would evolve once hundreds or thousands of students began using it.

When we eventually looked at the code itself, the picture became even clearer. The structure lacked consistency, there were obvious security concerns and the application had become increasingly difficult to understand because AI had been allowed to generate large amounts of code without the level of technical oversight that commercial software demands.

One of our senior developers summed it up rather succinctly after reviewing the project:

"This is going to be extremely hard to work with, if not impossible, from what we've seen so far."

The Real Lesson

It wasn't the conversation the founder was expecting, and it certainly wasn't the one he wanted to hear. He'd invested months into the project, genuinely believed he was only weeks away from launching and had already started making commitments based on that assumption. Looking back, it's impossible to criticise him for reaching that conclusion because he judged the platform in exactly the same way most business owners would have done. He looked at the screens, saw a significant amount of visible progress and naturally assumed the project was almost complete.

We were looking at something entirely different. We were looking at everything that still needed to happen before the platform could become secure, scalable, maintainable and capable of supporting the business he wanted to build.

The visible application represented only a small fraction of the work that still lay ahead, and that distinction fundamentally changed the direction of the project. Rather than completing the remaining twenty percent, we recommended stepping back, carrying out a proper Discovery process and rebuilding the platform on foundations that would support the founder's long-term vision instead of simply helping him reach launch day.

That experience reinforced something we've believed for many years. The quality of your software is determined long before the first line of code is written, and that's precisely why the best software teams spend far more time thinking than they do writing code.

The Software Iceberg: What You're Really Paying For

The review of the EdTech platform reminded us of something we've been trying to explain to clients for years. Businesses naturally judge software by what they can see because that's all they've ever had to evaluate. They see login screens, dashboards, reports, forms and mobile apps, so it's perfectly reasonable to assume that's where most of the effort has gone. In reality, those visible features are simply the end result of an enormous amount of thinking that has already taken place behind the scenes.

We've often described this using the analogy of an iceberg.

When you look at an iceberg floating in the ocean, only a small portion is visible above the waterline. The overwhelming majority sits beneath the surface, providing the stability that keeps the entire structure intact.

Software works in much the same way. The interface your users interact with every day represents only a fraction of what has actually been designed, discussed and built. Beneath the surface are the hundreds of decisions that determine whether the platform performs reliably, remains secure, scales gracefully and can continue evolving alongside the business for years to come.
 

The irony is that much of this work is invisible to clients because, if it's done properly, it never draws attention to itself. Users don't notice a well-designed database, they simply expect the application to respond quickly. They don't appreciate carefully planned permissions, they just assume the right people can access the right information. They rarely think about security until something goes wrong, and they almost never consider the countless discussions that took place before development began to ensure that the platform could continue supporting the business as it grows.

This is one of the reasons experienced software teams spend so much time asking questions before anyone starts building. To someone watching from the outside, those conversations can feel like progress has slowed because there are no new screens to demonstrate and no visible functionality being added. In reality, those early discussions are often the most valuable part of the entire project because they're where the difficult decisions are made while they're still inexpensive to change.

Discovery Is Where Great Software Begins

One of the biggest misconceptions in our industry is that software development starts when developers begin writing code.

From our perspective, development starts much earlier than that.

It starts with understanding the business, the people who will use the platform and the problem the software is actually trying to solve. Before we discuss technology, frameworks or programming languages, we want to understand how the business operates today, where the frustrations lie and what success should look like not only at launch, but several years into the future.

That's why our Discovery process is about far more than producing a specification document.

It's where we challenge assumptions, simplify ideas, identify risks and uncover opportunities that clients often haven't considered because they're experts in their own industries rather than software development. Those conversations shape every decision that follows, from how the database should be structured and how different users will interact with the platform, to which functionality genuinely belongs in the MVP and which ideas are better introduced once the business has gained traction.

If we'd met the founder of the EdTech platform before a single screen had been generated, our first few weeks wouldn't have involved writing code. We'd have spent time identifying every type of user who would interact with the platform, mapping each of their journeys, defining permissions, prioritising the MVP and discussing how the platform might evolve as more schools, teachers and students came on board. We'd have explored reporting requirements, future integrations, scalability, security and how success would be measured over time.

None of that work would have looked particularly exciting.

In fact, to someone unfamiliar with software development, it might even have appeared that very little progress was being made.

The reality is exactly the opposite, every decision made during Discovery strengthens everything that follows. It gives the entire team confidence that they're solving the right problem, building the right solution and laying foundations that won't need to be revisited once the platform begins growing.

After more than twenty years of building custom software, we've found that around seventy percent of the thinking happens before development truly begins. That statistic often surprises people because they imagine software projects as developers sitting behind keyboards writing code all day. In reality, the best developers spend a significant amount of time discussing ideas, challenging one another's assumptions and thinking through scenarios that users may never encounter, but which the platform still needs to handle reliably if it's going to succeed.

That's the work clients are really investing in. Not simply the ability to produce code but the experience to make good decisions before that code is ever written.

"You're not paying experienced developers to write code. You're paying them to make the right decisions before they write it."

Great Software Is Designed Around People, Not Screens

One of the biggest misconceptions about software development is that the goal is to produce as many features as possible. It's an easy trap to fall into because features are tangible. They can be demonstrated, added to proposals and ticked off against a specification. From a client's perspective, it's often the easiest way to measure progress because every sprint results in something new that can be seen and interacted with.

Experienced developers tend to see things rather differently.

Features are important, but they're only valuable if they help people achieve something in the simplest and most intuitive way possible. A platform with fewer, well-designed features will almost always outperform one that's packed with functionality but forces users to think too hard about what to do next. That's because people don't judge software by the number of screens it contains. They judge it by how effortlessly it helps them achieve their goal.

This is where artificial intelligence has made extraordinary progress, but also where its limitations become most apparent.

AI is remarkably good at generating interfaces. Given a well-written prompt, it can produce attractive dashboards, forms and layouts in a matter of minutes, and many of those interfaces look every bit as professional as something created manually. What it still struggles to understand is how real people behave once they begin using the platform. It doesn't recognise the hesitation a user experiences when they're presented with too many choices, the frustration of being asked for unnecessary information or the confusion that arises when a workflow makes perfect technical sense but very little practical sense to the person sitting behind the screen.

Those are not design decisions. They're business decisions, informed by experience.

When we reviewed the EdTech platform, this became obvious very quickly. The application contained more than forty screens, yet only one user journey had really been considered from beginning to end. Teachers, students, administrators and future stakeholders would all interact with the platform in completely different ways, but those experiences hadn't yet been mapped out. The software looked substantial because there were plenty of screens to click through, but the thinking that connected those screens into a coherent experience simply hadn't happened.

That's an important distinction because good software isn't a collection of screens. It's a collection of carefully designed decisions.

The Questions That Shape Great Software

One of the biggest differences between experienced developers and those who are newer to the profession has very little to do with programming ability. It comes down to the questions they ask before a solution has been agreed.

A founder naturally focuses on the opportunity they're trying to create. They think about customers, growth, operational efficiency and the value the platform will bring to the business. That's exactly where their attention should be because they're the experts in their industry.

An experienced development team approaches the same conversation from a different perspective. Years of building commercial software teaches you that every successful platform eventually encounters situations that weren't obvious at the beginning. User numbers increase, databases grow, new business processes emerge, regulations change and integrations evolve. The software that worked perfectly for fifty users may need to support fifty thousand users a few years later, and decisions that seemed insignificant during the first sprint suddenly become critically important.

Those experiences fundamentally change the questions you ask.

Instead of asking whether a feature can be built, we ask what happens when that feature needs to support ten times as many users. Instead of focusing purely on today's requirements, we're already thinking about how easily the platform can accommodate the changes the client is likely to request over the next three to five years. We consider whether another developer will understand the codebase in the future, whether the database has been designed to cope with millions of records instead of thousands and whether introducing a new feature six months from now will require a straightforward enhancement or a costly redesign.

None of those questions are intended to make a project more complicated. They're intended to stop it becoming more expensive.

Thinking Beyond Launch Day

One of the biggest differences we've noticed between successful software projects and those that struggle is the point at which the team stops thinking. Projects that focus entirely on getting to launch often achieve exactly that. They launch. Unfortunately, they also discover that the first six months after launch introduce a completely new set of challenges that nobody had planned for.

Real users behave differently to test users. Businesses evolve and new opportunities emerge. Customers request functionality that nobody originally considered.

Integrations need to be expanded, reporting requirements become more sophisticated and performance expectations increase as adoption grows.

If the platform has been designed with those realities in mind, it evolves naturally alongside the business. If it hasn't, every new requirement becomes progressively harder to implement because the original foundations were never intended to support that level of growth.

This is one of the reasons we spend so much time talking about scalability during Discovery. We're not suggesting that every MVP should be built as though it's supporting millions of users on day one. That would be unnecessary and commercially irresponsible. What we are saying is that every MVP should be designed so it can grow without forcing the business to start again once traction begins.

We've inherited too many platforms where developers became afraid to change the code because nobody fully understood how the different parts of the application interacted. We've seen databases that worked perfectly with a few thousand records but slowed dramatically once real volumes of data began arriving. We've reviewed applications where every new feature unexpectedly broke existing functionality because the codebase had become so tightly coupled that even small changes created unpredictable consequences.

Those aren't coding problems but more importantly they're thinking problems.

And they almost always originate from decisions that were made, or not made, at the very beginning of the project.

"The best software isn't the software that's quickest to launch. It's the software that's easiest to improve."

When Rebuilding Becomes The Most Cost-Effective Option

One of the hardest conversations we ever have with a client is explaining that continuing to build on their existing platform is likely to cost more than rebuilding parts of it properly.

No client wants to hear that (understandably so)!

By the time that conversation happens they've usually invested significant amounts of time, money and emotional energy into the project. They've demonstrated the platform to investors, spoken to prospective customers and started planning around an anticipated launch date. Suggesting that parts of the application should be rebuilt can feel like asking them to abandon months of progress.

The reality, however, is that software isn't measured by the amount of code that's been written. It's measured by the quality of that code and, more importantly, by the quality of the thinking that shaped it.

We experienced this first-hand when we were asked to take over another commercial software platform that had originally been built by what appeared to be an experienced development team. From the outside, there was very little to suggest anything was wrong. The platform looked mature, many of the core features were already in place and the client believed they simply needed a new team to continue developing additional functionality and to add velocity to the project.

It didn't take long for our developers to realise that something wasn't right.

As we spent more time reviewing the application, it became apparent that large parts of the codebase had been generated using artificial intelligence with very little technical oversight. Instead of a well-structured, modular application that another developer could confidently understand and extend, we found a codebase that had become unnecessarily bloated, inconsistent and increasingly difficult to maintain. Similar functionality had been implemented in different ways throughout the application, code was duplicated in places where it should have been reusable and seemingly simple changes carried a surprising amount of risk because nobody could be completely certain what else might be affected.

The issue wasn't that the code failed to work, in fact much of it did.

The problem was that it had never been written with the expectation that another experienced developer would one day need to maintain it, extend it or troubleshoot it under pressure. Every new feature made the platform slightly more complicated, every release carried more uncertainty than it should have and the amount of time required simply to understand the existing codebase continued to grow.

Eventually we reached a conclusion that no development team enjoys delivering.

Rebuilding significant sections of the platform would actually be faster, safer and more cost-effective than trying to repair what already existed.

To someone outside the software industry that probably sounds counterintuitive. Surely improving existing code is always quicker than starting again? Unfortunately, that's not always the case.

Imagine renovating a house where every previous extension had been built without proper plans, different builders had used different materials and nobody could tell you which walls were load-bearing. At some point, continuing to patch the structure becomes more expensive than rebuilding parts of it properly. Software behaves in much the same way. If the underlying foundations are weak, every improvement becomes progressively harder because you're spending more time working around earlier decisions than moving the platform forward.

Once those parts of the application had been rebuilt using clean, modular code and a structure that the entire team understood, the difference was immediate. The platform became noticeably faster, easier to maintain and significantly simpler to extend. More importantly, everyone involved could finally develop the application with confidence because they understood how the different parts worked together and could predict the impact of future changes.

That experience reinforced another lesson we've learnt repeatedly over the years.

Artificial intelligence doesn't remove the need for experienced developers. It increases the importance of them.

AI Is An Incredible Tool. It's Not A Strategy.

It's worth saying this clearly because it's easy to misunderstand the message of this article.

We are not against artificial intelligence in fact it’s quite the opposite!

Our developers use AI every single day because it makes us more productive, helps us explore different approaches more quickly and removes much of the repetitive work that has traditionally consumed valuable development time. Used responsibly, it's one of the most significant productivity improvements our industry has ever seen.

The difference is that we don't confuse generating code with making good technical decisions.

Every suggestion produced by AI is reviewed, challenged and refined by experienced developers who understand the wider context of the application they're building. Sometimes the suggested solution is excellent and can be used with very little adjustment. Sometimes it provides a useful starting point that needs further refinement. Occasionally it's simply the wrong approach because it doesn't take into account performance, maintainability, scalability or the long-term direction of the platform.

That's exactly how AI should be used. Not as the developer, nor as the architect and certainly not as the person making the decisions.

As an exceptionally capable assistant that allows experienced people to spend more time doing what humans still do best: thinking critically, solving complex problems and making informed decisions that balance technical excellence with commercial reality.

As AI continues to evolve, we actually believe those human skills will become even more valuable. When every business has access to increasingly capable development tools, the competitive advantage is no longer who can generate the most code in the shortest amount of time. It belongs to the teams that consistently make the best decisions before, during and after development.

That's why we believe the future of software development isn't about choosing between artificial intelligence and experienced developers.

It's about combining the strengths of both.

"Artificial intelligence helps developers build software faster. Experience determines whether they're building the right software in the first place."

The Future Belongs To Teams That Think Better

One of the biggest mistakes people make when talking about artificial intelligence is assuming the conversation is about choosing between AI and experienced developers.

We don't believe that's the choice businesses will be making over the next decade. In fact, we think the opposite will happen. As AI becomes more capable, the organisations that achieve the greatest success will be those that combine the speed of artificial intelligence with the judgement, commercial awareness and technical experience that only people can bring.

If everyone has access to the same AI tools, then generating code quickly is no longer a competitive advantage. The differentiator becomes the quality of the decisions that shape the software before, during and long after development has begun. Those decisions influence everything from the user experience and database design to security, scalability, maintainability and how confidently the platform can evolve as the business grows.

They're also the decisions that determine whether new features can be introduced with confidence or whether every enhancement becomes progressively slower, riskier and more expensive.

Over the last twenty years we've learnt that successful software projects rarely succeed because somebody wrote exceptional code. They succeed because the right questions were asked at the beginning, the difficult conversations happened early, assumptions were challenged before they became expensive mistakes and the team never lost sight of the business problem they were trying to solve. Writing the software is obviously important, but it's only one part of a much bigger process that combines commercial understanding, technical thinking and years of practical experience.

That's one of the reasons we've become so passionate about Discovery. It isn't a box-ticking exercise or an opportunity to produce lengthy documentation that nobody reads. It's where businesses and experienced developers come together to build a shared understanding of the problem before deciding on the solution. It's where priorities are challenged, risks are identified and ideas are refined until everyone has confidence that the platform being built is not only right for today, but capable of supporting where the business wants to be several years from now.

When we look back at both of the projects we've shared in this article, it's interesting that neither of them failed because artificial intelligence wasn't capable enough. They struggled because the thinking that should have guided the technology never really happened. In one case, a founder understandably believed that an impressive-looking interface meant the platform was almost complete.

In the other, a development team relied too heavily on AI-generated code without applying the discipline needed to ensure the software remained clean, maintainable and scalable. The technology wasn't the problem. The absence of experienced oversight was.

That's why we believe the role of experienced developers is becoming more valuable, not less. As AI continues to remove repetitive work and accelerate delivery, developers have more time to focus on the things that genuinely differentiate great software from average software. They can spend more time understanding businesses, improving user journeys, simplifying complexity, strengthening security, planning for scale and making thoughtful technical decisions that continue paying dividends long after the platform has been launched.

In many ways, that's exactly how software development should evolve.

Where Do You Go From Here?

If there's one idea we'd like you to take away from this article, it's that software development has never really been about writing code. Code is simply the outcome of hundreds of decisions that begin long before development starts and continue throughout the lifetime of the platform. Artificial intelligence has changed how those decisions are implemented, but it hasn't changed how important they are.

Whether you're building an MVP, modernising an existing platform or wondering whether your current software is ready for its next stage of growth, our advice is always the same. Invest time in thinking before you invest in building. The conversations you have before development begins will almost always have a greater impact on the long-term success of your platform than the speed at which the first features are delivered.

At Elemental, we've spent more than twenty years helping founders, SMEs and established businesses turn ambitious ideas into secure, scalable software platforms. Sometimes that means designing something entirely new. Sometimes it means reviewing an existing platform and identifying opportunities to improve it before those issues become expensive to fix. Either way, our role is the same. We help our clients make better technology decisions by combining practical development experience with a structured Discovery process that creates clarity, reduces risk and gives every project a much stronger foundation.

If you're planning a new software project, evaluating an existing platform or simply want an experienced second opinion before making an important technology decision, we'd love to have a conversation. Even if that conversation confirms you're already heading in the right direction, you'll leave with a clearer understanding of the opportunities, risks and decisions that will shape the future of your platform.

Because after more than two decades of building custom software, one lesson has remained remarkably consistent.

“The quality of your software is determined long before the first line of code is written.”