AI CAN GENERATE CODE. DO YOU NEED A CUSTOM BUILD?
As a software engineer, I can build custom digital systems. I also know when not to. Here is how I decide between no-code, low-code and custom development, and why the right technical choice depends on far more than how quickly AI can generate the code.
Here’s my hot take: I am a software engineer who does not recommend custom development for every project. Writing code is one part of building a digital system. The harder questions usually come before and after it:
What should be built?
Which requirements are real?
What remains an assumption?
Who will maintain the system?
How easily can it change?
Does custom functionality create enough value to justify the complexity it introduces?
AI has made code easier to produce
AI can now generate layouts, components and application logic in minutes. It can troubleshoot errors, suggest architecture and turn a written description into something resembling a working product.
AI has changed the speed and economics of development. It has also made sound technical judgment and restraint more important.
Generated code still needs to be understood, tested, secured and maintained.
Integrations may fail. Requirements change. Users behave differently from how we imagined they would. A system that works in a demonstration may not be resilient enough to support everyday use.
AI can produce software before earning clarity about what the software needs to do.
This is one reason no-code and low-code remain valuable.
Custom development creates ownership
A custom system gives an organization greater control over its functionality and experience. It can support distinctive interactions, complex data structures and requirements that existing platforms cannot accommodate well.
It also creates responsibility.
Someone must understand the architecture. Dependencies need to be maintained. Security issues require monitoring. Features need to be tested when changes are introduced. Documentation should remain current.
The first version may be fast and inexpensive to create. However, the long-term cost of a system is not captured by token spend or hours it took to complete.
The more useful measure is the organization’s ability to understand, operate, adapt and maintain the software. For some organizations, that responsibility is justified because the custom functionality is central to what they offer. For others, it creates a technical burden without producing proportional value.
Existing platforms contain years of solved problems
When using an established platform, you are choosing infrastructure in which many common problems have already been addressed, including content management, responsive layouts, user permissions, hosting, security updates, backups, forms, publishing workflows and integrations.
This allows more of the project’s budget and attention to go toward the decisions users will actually notice:
Is the positioning clear?
Is the information structured around their needs?
Does the website establish trust?
Do the conversion pathways make sense?
Can the internal team manage the system?
Does the digital experience reflect the organization rather than the platform?
A no-code or low-code website can still require sophisticated thinking. The platform may provide the components, but it does not determine the strategy, structure or quality of the system assembled from them.
The decision to use existing infrastructure can therefore be an engineering decision in itself.
Developers routinely rely on frameworks, libraries, APIs and cloud services instead of rebuilding every layer of a system. No-code and low-code platforms can be evaluated through the same principle: do they provide a reliable foundation for the requirements that actually matter?
Early projects should be optimized for learning
A new website, service or product usually contains more assumptions than its creators realize.
We assume we understand the audience, the features they would want, and the pathway they will follow. We also assume that the proposed workflow reflects how an organization operates.
Custom development can encode those assumptions very quickly. Once they become features, interfaces and integrations, changing direction becomes expensive.
Lean startup methodology offers a useful alternative.
The earliest version of a product should be the smallest credible way to test the most consequential assumption.
Sometimes that requires custom code. Other times a simple landing page with a form and a manually delivered service will suffice.
A no or low-code website provides enough infrastructure to test positioning, demand and user behaviour before a larger investment is justified.
The sophistication of the solution should match the question being tested. This is why I often prefer an established platform while an organization is still learning what the system should become. It preserves agility — the ability to change direction without treating every discovery as a redevelopment project.
No-code is not always the leaner choice
No or low-code platforms and custom development function at different levels of intervention.
A system can become fragile when it depends on too many plugins, disconnected automations or layers of custom code. Platform limitations can force awkward workarounds, while subscription costs can accumulate. A website chosen for easy maintenance can gradually become impossible for the internal team to manage. There is a point at which working around a platform costs more than moving beyond it.
Custom development becomes more compelling when:
distinctive functionality is central to the product;
existing platforms materially restrict the user experience;
complex data, permissions or integrations are essential;
workarounds are accumulating;
the workflow has been tested and is stable enough to encode;
the organization has the resources to maintain what it builds.
The answer may also be hybrid: an established platform for content and administration, connected services for specialized functions and custom code only where it creates a meaningful advantage.
The goal is not to build the most technology
As an engineer, I could frame every project as an opportunity to write more code. But maximizing technical complexity does not serve my clients well.
My job is to make sound decisions under real constraints, and the solution may be targeted customization, thoughtfully configured existing infrastructure or small amounts of code introduced where they create the greatest value.
The right question boils down to:
What is the lightest reliable system capable of supporting what this organization needs right now, without obstructing what it may need next?
That is the standard I use when deciding what deserves to be built, how it should be built and how much technology a project actually requires.
Not sure what level of build you need?
I help organizations choose and build the level of digital infrastructure that best fits their goals, resources and next stage of growth, across no-code, low-code and custom development.
That might mean creating a strategic website on an established platform, extending it with purposeful code, connecting the tools you already use or developing a more bespoke system where the requirements genuinely call for it.
For projects where Squarespace is the right foundation, eligible clients can also access benefits or discounts through my Squarespace Circle membership.