I spent twelve years building software that lived behind a login. Warehouse systems, back offices, the kind of application where the users are employees who have to use it whether they like it or not. When I closed that chapter in 2023 and founded Essential Code, I quietly assumed website development would be the easier discipline. That assumption cost me most of a year pointing the company at consulting and SaaS ideas before I looked properly at what web work had become.
The assumption was wrong in a specific way, and a lot of technically strong people get it wrong the same way. A B2B application has a captive audience. Its users are trained, contractually present, and unable to leave when the interface annoys them. A public website has none of that. Its visitors are unwilling, its performance is measured by a third party, its content is graded by an index nobody at the project controls, and for a good number of sites its accessibility is now law, through the European Accessibility Act that has applied since 28 June 2025. That is a harder environment to build for, and it took me a while to see it as anything other than a simpler one.
A note for readers searching B2B web application development: Essential Code today builds marketing websites and customer portals on a headless stack. We still take on authenticated B2B applications when they fit a customer portal model. See our writeup on the customer portal stack we use and the Essential Launch Framework for how we structure those projects. This post is about how the agency got here.
What transferred from enterprise work, and what did not
Twelve years of application work is neither an automatic qualification nor useless experience. It splits cleanly:
| Transferred directly | Had to be learned from scratch |
|---|---|
| Data modelling. A content model is a schema with editors attached | How a search index actually treats a site after it changes |
| Integrations, and the habit of owning an API dependency after go-live | Editor experience, and how quickly a bad model stops a team publishing |
| Error paths. What the page does when the third-party system is down | Design fidelity as a deliverable rather than a preference |
| Permissions and authentication for anything behind a login | Performance budgets on other people’s phones and networks |
| Scoping discipline, learned expensively | Content operations across languages and markets |
The left column is why we can build a portal or a configurator instead of pasting in whatever widget the vendor supplies. The right column is why the first year was slower than I expected.
Scoping is the item I would defend hardest. Twelve years of watching overscoped projects run past their budget and their date is the reason I now argue clients out of features more often than into them.
Where an enterprise background gets expensive
The same instincts that make complex systems reliable make simple websites expensive. This is my own failure mode, so I recognise it fast in other people’s proposals.
- Infrastructure sized for a load that will never arrive: dedicated servers, container orchestration and a database for a site that serves identical content to every visitor. We wrote about a real version of this in the trust problem in the web industry, where an agency recommended exactly that for a corporate site with a blog.
- Forty hours of custom development for something a documented service already does.
- Content structures modelled around a market entry, a product line or a workflow nobody has committed to, which an editor then has to maintain without understanding why the fields are there.
- Design treated as decoration, which is the habit of internal tooling, where an interface is judged on whether it works. On a public site the design is part of what works.
That is a correct instinct applied to the wrong class of problem, which is the most expensive kind of mistake to catch, because it arrives sounding confident.
How to tell which one you are buying
The practical question for a marketing team is whether a provider’s depth is pointed at your problem. Four questions get you there:
- What does this infrastructure protect me against, and how likely is that? A good answer names a specific risk. Watch for descriptions of scale you have no plan to reach.
- Which parts of this would you buy instead of build? Anyone who would build everything is either very expensive or very junior.
- What breaks first when this site gets busy, and what breaks first when the platform underneath changes its API? The second half of that question is the one that separates people who have run systems from people who have launched them.
- Who owns this after launch? Enterprise projects have a maintenance contract by default. Website projects often have nobody, and that is where the depth actually earns its money.
Where the depth actually pays off
On a brochure site with five pages, it does not, and pretending otherwise would be selling. It starts to matter the moment a site has a system behind it.
A ticketing platform is the clearest example. Every one of them ships an embed widget you paste into a page in twenty minutes, and it renders in its own typeface inside a box with its own scrollbar. Building against the platform’s API instead, so an event is a page of the site with its own address, is ordinary application work applied to a marketing problem. We wrote up how that played out on a real project in your ticketing platform should not decide what your site looks like. The same fork appears with booking systems, shops, member areas and anything behind a login.
Without that capability in the room, the answer to “can we do this properly” is always the widget, because it is the only answer available. The scope quietly shrinks to whatever the tools do on their own.
What changed again after that
The 2023 change was about the discipline. The second one, two years later, was about how the work gets done.
When we repositioned Essential Code around AI, what I stopped selling was writing all the code by myself, being in the midst of it, my identity as a software developer. I had to bet the agency on AI to stay on top of the game as a solopreneur in times where AI is everywhere. Twelve years of building applications turned out to be excellent preparation for reviewing work rather than typing it, which is not what I expected to be doing at this point and is closer to the architecture end of the job than the coding end.
What has not changed since 2011 is the part I would still put in writing: the thing has to actually work, under load, on a bad connection, when the system it depends on is having a bad day. Today I run Essential Code as a micro agency, and for design studios that need technical delivery under their own brand, we work as a white-label development partner.
If your website has systems behind it and you are not sure whether the setup fits the load, a Headless Audit tells you what is actually there before anyone proposes a rebuild.