Building for Today’s Quest or Tomorrow’s Empire?

Every shortcut is a promise the future must eventually keep.

The First Road Beyond the Castle Gates

Long before a kingdom becomes an empire, someone chooses where the first road will be built. Travelers may never remember who laid those stones, but generations will depend upon the decision. Software is built much the same way. Long before users celebrate new features, someone quietly decides how the application will grow, how its parts will work together, and whether future engineers will inherit a thriving kingdom or spend their days repairing crumbling foundations.

When I first began writing software, I believed every project had a finish line. Complete the feature, fix the bugs, deploy the release, and move on to the next adventure. Experience eventually taught me something very different. The most successful software rarely reaches an end. Instead, it continues to grow year after year as new requirements, new users, and new ideas reshape what it was originally built to be. That realization changed the way I think about system design far more than learning any framework or programming language ever did.

Every architect eventually faces the same difficult question. Are we building for today’s quest, or are we laying the first stones of tomorrow’s empire? Lean too heavily toward today’s immediate needs, and tomorrow’s developers inherit unnecessary obstacles. Build too aggressively for an uncertain future, and the project becomes weighed down by complexity that serves no one. Good architecture lives somewhere between those extremes, where thoughtful preparation meets practical restraint.

As we continue our journey through Foundations of the Kingdom, this balance becomes one of the most important lessons an engineer can learn. Every enduring kingdom rests upon choices few people ever see. Visitors admire towering walls, magnificent keeps, and bustling cities, but almost nobody thinks about the roads beneath their feet or the foundations hidden below the stone. Software works the same way. Users remember useful features. Developers inherit the engineering decisions that made those features possible.

Fantasy kingdoms illustrate this beautifully because they are built one decision at a time. A wise ruler does not begin with towering citadels and sprawling districts stretching to the horizon. The first concern is whether the settlement can survive its earliest winters. Fresh water must remain accessible. Roads must connect neighboring villages. Supplies must reach the marketplace before decorative towers ever become important.

Software follows exactly the same pattern. Our earliest decisions rarely appear in release notes or marketing announcements, yet they influence almost everything that comes afterward. Long before customers notice new capabilities, someone has decided how responsibilities are divided, where data belongs, how components communicate, and how future change will be accommodated. Those decisions become the bedrock upon which every future feature is built. The greatest architectural decisions are often invisible precisely because they continue serving the kingdom long after everyone has forgotten they were ever made.

The Master Mason Does Not Predict the Future

One misunderstanding I have encountered throughout my career is the belief that software architects are expected to predict the future. Nothing could be further from reality. I have never met an engineer who could accurately forecast every feature request, every business decision, every acquisition, or every technology shift that would affect a system over the next five years. The future always surprises us. Good architecture simply makes those surprises less painful.

That distinction completely changed how I evaluate design decisions. Rather than asking whether I have anticipated every possible requirement, I ask whether today’s implementation unnecessarily limits tomorrow’s opportunities. Architecture is less about prediction than preservation. Every thoughtful boundary keeps another path available, while every careless shortcut quietly closes another gate the team may someday wish remained open.

Imagine a master mason standing beside an empty valley where the kingdom plans to construct its first stone bridge. He cannot know how many merchants, soldiers, or pilgrims will cross that river a century from now. He does not attempt to predict the exact future. Instead, he chooses solid bedrock, leaves space for future expansion, and avoids placing permanent structures where they would impede later improvements. His wisdom lies not in seeing the future clearly, but in refusing to block it unnecessarily.

I have found that good software design rewards exactly the same mindset. Every class, interface, API, and database schema either leaves room for future growth or quietly removes it. We are not trying to build for every imaginable future. We are trying to avoid trapping tomorrow’s engineers inside today’s assumptions.

That philosophy has guided many of my own architectural decisions over the years, especially when the pressure to deliver quickly tempted me toward shortcuts. I have also learned that changing my mind is not a sign that the original design failed. Some of the best architectural decisions I have ever made came after recognizing that the software had outgrown my first assumptions. Sometimes the fastest solution truly is the correct solution. More often, the right answer is the one that leaves just enough room for the software to evolve naturally as our understanding evolves.

Building the King’s Road Instead of a Goat Trail

One lesson took me much longer to appreciate than I would like to admit. Software has two costs. The first is writing it. The second, and usually much higher cost, is living with it.

Most feature requests arrive with deadlines attached. Product owners want customer value delivered quickly, stakeholders want visible progress, and developers naturally focus on satisfying the immediate requirement. There is nothing wrong with that. Shipping software matters. An elegant design that never reaches production helps nobody. The danger appears only when every decision favors today’s convenience while quietly increasing tomorrow’s maintenance.

Suppose our kingdom needs a simple road connecting two nearby villages. The quickest solution is to clear a narrow trail through the forest. Travelers reach their destination, construction finishes early, and everyone celebrates another completed project. At first glance, the decision appears perfectly reasonable.

</> JavaScript

app.get('/customers/:id', async (req, res) => {
    const customer = await db.query(
        'SELECT * FROM Customers WHERE id = ?',
        [req.params.id]
    );

    res.json(customer);
});

There is absolutely nothing wrong with this implementation in the proper context. If I were building a small internal reporting tool expected to live for only a few months, I would likely stop here without hesitation. Good engineering always considers context before applying principles.

The trouble begins when the quiet forest trail becomes the kingdom’s busiest trade route. Soon, merchants require wider roads. Soldiers need reliable travel during winter. Inns appear beside the roadway. Bridges must carry heavier wagons. What began as a practical shortcut gradually becomes the most expensive piece of infrastructure to replace because every future improvement now depends upon it.

Software evolves in exactly the same way. Authentication appears. Logging becomes necessary. Business validation grows more sophisticated. Performance concerns introduce caching. Suddenly, every controller duplicates similar logic with small variations, and a simple enhancement requires modifications across half the application.

A modest architectural investment changes that future dramatically.

</> JavaScript

app.get('/customers/:id', async (req, res) => {
    const customer = await customerService.getCustomer(req.params.id);
    res.json(customer);
});

The controller now owns only the responsibility of handling the request. The service layer serves as the kingdom’s well-built road, carrying business rules, validation, authorization, logging, caching, and future enhancements along a single, well-maintained path. The application has not become dramatically more complicated, yet it has become dramatically easier to extend.

That distinction illustrates one of the most valuable lessons I have learned during my career. I do not separate responsibilities because every application deserves enterprise architecture. I separate responsibilities because clear boundaries preserve future possibilities. Every shortcut is a promise the future must eventually keep, and I would rather leave the next engineer a well-built road than a goat trail that happened to reach its destination first.

Leaving Gates Unlocked for Future Builders

One principle has become increasingly important to me as I have gained experience: make the important decisions as late as reasonably possible. That advice often sounds backward to newer developers because we naturally want certainty before we begin building. In reality, the opposite is usually true. The more information we gather before committing to an irreversible design, the better our decisions become. Good architecture is not about delaying work. It is about delaying the handful of decisions that become painfully expensive to undo while making the decisions that create a solid foundation today.

Think again about the kingdom we have been constructing. The location of the castle is almost impossible to change after construction begins. The width of the main gate is difficult to modify once massive stone walls surround it. Those choices deserve careful planning because they quickly become permanent. Decorative banners, market stalls, and the placement of a fountain can all be changed later with relatively little effort. Wise architects devote their greatest attention to decisions that are hardest to reverse because those decisions shape every project that follows.

Software contains the same kinds of choices. Determining where business rules belong, defining the boundaries between major components, deciding who owns data, and designing public APIs all become progressively more expensive to change as a system grows. On the other hand, replacing a logging library, reorganizing helper methods, or changing the appearance of a user interface is usually far less disruptive. Experienced engineers learn to distinguish between foundational and cosmetic decisions because not every discussion warrants the same level of architectural attention.

This way of thinking naturally leads to another concept that has profoundly influenced how I design software: creating seams. A seam is simply a place where future change can occur without requiring the rest of the application to change with it. Good seams isolate responsibilities so that improvements remain local rather than rippling throughout the entire codebase. They do not eliminate future work. They simply make future work less expensive.

Consider a service that communicates directly with a database.

</> JavaScript

class CustomerService {
    async getCustomer(id) {
        return await sql.query(
            'SELECT * FROM Customers WHERE id = ?',
            [id]
        );
    }
}

At first glance, this implementation appears perfectly reasonable. The service retrieves customer information and returns the result. The difficulty appears later if the application introduces caching, automated testing, or even a different persistence technology. Because the service depends directly upon SQL, every one of those improvements now begins by untangling responsibilities that were never meant to be tightly coupled.

Introducing a repository creates a seam where future improvements can occur without disrupting the rest of the kingdom.

</> JavaScript

class CustomerService {
    constructor(customerRepository) {
        this.customerRepository = customerRepository;
    }

    async getCustomer(id) {
        return await this.customerRepository.findById(id);
    }
}

The service no longer cares whether customer information comes from SQL Server, PostgreSQL, an external API, a distributed cache, or even an in-memory collection used during testing. That flexibility was not added because I know the database will someday change. It exists because separating responsibilities produces healthier software regardless of whether the database ever changes. The seam leaves future paths open without introducing unnecessary complexity.

Knowing Which Walls Deserve Stone

One of the greatest temptations in software architecture is believing that flexibility always requires more abstraction. I certainly believed that earlier in my career. Every new project became an opportunity to introduce another factory, another generic interface, another extension point, or another configuration system. My intentions were good. I wanted every application to be prepared for every possible future.

Most of those futures never arrived.

That realization taught me another lesson that has remained with me throughout my career. There is a tremendous difference between preparing for likely growth and preparing for unlimited possibilities. One reflects engineering judgment. The other often becomes speculative engineering that consumes time, attention, and maintenance without creating corresponding value.

Imagine a castle whose ruler insists that every watchtower include docking platforms for dragons, despite the kingdom having never seen a dragon in its history. Additional staircases are constructed. Reinforced platforms are added. Specialized supplies are stockpiled. Years later, there are still no dragons, but the kingdom continues paying to maintain infrastructure that never served a practical purpose. The castle became more complicated without becoming more useful.

Software teams sometimes fall into exactly the same trap.

Suppose an application sends an email confirmation after a customer places an order. One implementation might look like this.

</> JavaScript

emailService.sendOrderConfirmation(order);

Simple. Direct. Easy to understand. It solves the problem the business actually has.

Sometimes developers immediately replace it with something considerably more elaborate.

</> JavaScript

notificationFactory
    .createProvider(configuration)
    .buildDispatcher()
    .dispatch(orderNotification);

Could the second design eventually become valuable? Absolutely. Does the current application need that level of flexibility today? Very often, the honest answer is no.

One question has saved me from introducing countless unnecessary abstractions over the years.

What real requirement does this solve today?

If the only answer is that it might someday become useful, I usually wait. Refactoring is part of software development. We are allowed to improve designs as requirements mature. In fact, some of the cleanest systems I have worked on emerged because the abstractions were introduced only after the software revealed where flexibility was genuinely needed.

That approach requires confidence because it asks us to resist solving tomorrow’s imagined problems before today’s real ones are resolved. Newer developers sometimes worry that postponing an abstraction makes them shortsighted. I have found the opposite to be true. Waiting until patterns emerge allows me to design around facts instead of assumptions. The resulting structure is usually simpler, easier to explain, and far more resilient because it grew from real experience rather than speculation.

The Kingdom Must Still Pay Its Builders

Architecture always competes with reality. Schedules remain fixed. Budgets remain limited. Customers rarely ask whether a feature required beautiful abstractions before deciding whether it solved their problem. Those pressures are real, and experienced engineers acknowledge them rather than pretending they do not exist.

At the same time, responsible developers understand that speed and quality are not opposing forces. They are partners that must remain in balance. Delivering software quickly matters because unused code creates no value. Delivering maintainable software matters because successful applications continue changing long after their first release. The challenge is recognizing which architectural investments produce lasting value and which merely delay useful work.

Over the years, I have found that relatively small investments consistently produce remarkable returns. Clear naming. Logical project organization. Cohesive modules. Well-defined interfaces. Automated tests protecting critical business rules. None of these requires months of planning, yet each one makes the next feature easier to build. Those are the investments I almost never regret.

By contrast, I have often regretted building elaborate extension systems before anyone needed them. Every additional abstraction carries a maintenance cost. Every new concept becomes another idea that future developers must understand before making progress. Good architects spend complexity as carefully as kingdoms spend gold. Both resources disappear much faster than anyone expects.

The Architect Who Builds for People, Not Projects

One lesson has remained remarkably consistent throughout my career. Architecture is not measured by how impressive the diagrams appear during a design meeting. It is measured by how calmly a team responds when requirements inevitably change. The best architectures rarely call attention to themselves because they quietly absorb change rather than resist it. They allow developers to spend their time building new capabilities rather than dismantling old decisions. That kind of resilience is never an accident.

Whenever I begin a new project, I ask myself a handful of questions before committing to an architectural decision. Will this code likely be extended? Will another developer need to understand it six months from now? Is this decision inexpensive to change later, or will it become embedded throughout the application? Would another hour of thoughtful design save weeks of future maintenance? None of these questions guarantees perfect answers, but together they consistently lead toward better ones.

I have also learned to think carefully about how a project is organized because structure communicates intent long before anyone begins reading implementation details. Consider the difference between these two directory layouts.

A project that grows organically without clear boundaries often begins to resemble this.

src/
    auth.js
    customer.js
    order.js
    email.js
    utils.js
    helpers.js
    database.js
    validation.js
    logger.js

Nothing here is technically incorrect. Every file has a purpose, and many successful projects begin this way. As additional features arrive, however, responsibilities gradually become scattered throughout the project. Developers spend more time searching than building because related functionality no longer lives together. The application still functions, but every enhancement becomes slightly more difficult than the last.

Now compare that with an organization built around the business itself.

src/
    customers/
        customerController.js
        customerService.js
        customerRepository.js

    orders/
        orderController.js
        orderService.js
        orderRepository.js

    shared/
        database.js
        logger.js
        validation.js

Neither structure guarantees success, but the second encourages cohesion. Customer concerns remain together. Order logic evolves independently. Shared infrastructure stays separate from business behavior. New developers can navigate the application by following the same mental model the business already uses. That clarity becomes increasingly valuable as the kingdom continues expanding.

Good architecture is rarely about making code more clever. More often, it is about making the system easier for ordinary developers to understand. I have discovered that the greatest compliment another engineer can give my work is not that it looks sophisticated. It is hearing them say they understood the design almost immediately. The strongest kingdoms are often the easiest to navigate because someone invested time making the roads obvious instead of merely making them functional.

Building a Kingdom Others Can Rule

One of the most important realizations of my career came when I stopped thinking of software as something I was building and started thinking of it as something I was eventually handing to someone else. Sometimes that future developer is a teammate. Sometimes it is the engineer who joins the project years later. Quite often, it is simply a future version of myself that has forgotten why a particular decision seemed so obvious at the time.

That perspective changes how we write software. Clear names become more valuable than clever implementations. Small, focused methods become preferable to sprawling functions that accomplish everything at once. Thoughtful documentation explains why a decision was made instead of repeating what the code already says. Every improvement reduces the effort required for the next developer to continue the work, rather than to decipher it.

I often remind younger engineers that code is read far more often than it is written. A feature that requires three days to implement may remain in production for ten years. During those years, it will be reviewed, debugged, extended, optimized, refactored, and occasionally rewritten. Spending another few minutes making its intent unmistakably clear is almost always one of the highest-return investments we can make.

This is why I encourage thoughtful refactoring even when customers never see the difference. Refactoring is not polishing code for its own sake. It is restoring the kingdom’s roads before another season of expansion begins. Strong foundations allow future construction to proceed confidently. Weak foundations force every new project to begin by repairing yesterday’s mistakes.

Wisdom Worth Carrying Into Every Quest

If there is one lesson I hope every developing engineer carries away from this chapter, it is this.

Build for the future you have reason to expect, not the future you can imagine.

Those few words have saved me from both extremes throughout my career. They have reminded me not to introduce unnecessary complexity simply because something might someday become useful. They have also prevented me from ignoring clear signs that an application was preparing to outgrow its original design. Good architecture grows alongside real requirements instead of racing far ahead of them or falling hopelessly behind.

That philosophy also reshaped the way I think about technical debt. Technical debt is not simply code that could be cleaner. Sometimes it represents a conscious decision to favor immediate business value while acknowledging that an improvement should be made later. Responsible engineers document those decisions, revisit them regularly, and pay down the debt before interest begins consuming future development. Irresponsible engineers simply pretend the debt does not exist until someone else inherits the burden.

Perhaps that is why software architecture continues to fascinate me after so many years. We are never truly building software for today alone. Every design decision becomes part of a conversation with engineers we may never meet, solving problems we cannot yet imagine. Our responsibility is not to predict exactly what they will need. Our responsibility is to leave them a kingdom that welcomes thoughtful growth instead of resisting it.

Leaving the Castle Gates Open

As we continue exploring Foundations of the Kingdom, I hope you begin seeing architecture less as a collection of patterns and more as a discipline of thoughtful decision-making. Every module, every interface, every database table, every project boundary, and every public API represents a choice about how future developers will experience the system. Most users will never notice those decisions directly, yet they benefit from them every time new features arrive smoothly instead of painfully. Every enduring kingdom rests upon choices few people ever see, and every successful software system is built exactly the same way.

In our previous chapter, Why Castles Need Architects, we explored why software requires intentional structure before meaningful growth can occur. This chapter expanded that foundation by examining one of the architect’s earliest responsibilities: deciding how much future belongs in today’s design. There will never be a formula that answers every situation because software is built by people solving human problems under constantly changing circumstances. There is only the discipline of balancing today’s needs with tomorrow’s possibilities, making careful decisions where they matter most while resisting the temptation to solve problems that do not yet exist.

If there is a common thread running through everything we have discussed, it is this: architecture is ultimately an act of stewardship. Every time we write code, we borrow time from the future. Sometimes that investment pays remarkable dividends because we prepared wisely. Sometimes it becomes technical debt because we chose convenience over clarity. The responsibility of an architect is not to eliminate every tradeoff. It is to make those tradeoffs deliberately, understanding which decisions deserve careful planning and which can safely evolve as the kingdom grows.

Today, we explored how to build with tomorrow in mind without allowing tomorrow to dominate today’s work. On Friday, we will examine the opposite danger. We will discover what happens when thoughtful preparation quietly becomes unnecessary complexity, and why even experienced engineers sometimes build magnificent towers for kingdoms that may never exist. Join me for The Curse of Premature Fortification, where we will learn that one of the greatest architectural mistakes is not building too little, but building far more than the kingdom has ever asked for.