One of our Edge Monsters Community members asked a great question recently:
“I am getting ready to start planning a 3–5-year journey/roadmap, looking ahead. Part of my schtick is to do a clean sheet design if I were starting over from scratch. Given the current date, 2026, what would folks do differently if you were starting over on Edge right now?”1
Let’s seek to answer it in this post. What would we do if we were starting over with an edge computing initiative today, in 2026? We’ll approach this in the context of something we shared in our last post: “architecture decisions echo”. This echo might reverberate for a long, long time. Therefore, it is imperative to think and build in a way that creates waves of positive echoes.
One theme ran underneath nearly everything the group raised, and it is worth stating up front that the technology is rarely the hardest part of an edge program. The hardest parts are the decisions, the people, and the organization around it. Keep that in mind as you read, because almost every regret below is a decision problem wearing a technical costume.
Act 1: Reframe the Problem
Ask “do I need this at all?” before anything else
Before defining a single layer or evaluating a single box, the most important question is the simplest one: do I need edge computing at all? Do I need Kubernetes? If you don’t need it, absolutely don’t build it. As always, implement the simplest possible solution that gives you what you need today, with consideration for what might come tomorrow, but not obsession over it.
Only once you’ve earned a “yes” does the next question become interesting: not “what’s our edge platform?” but “what is the right deployment approach for our problem set?”
Reframe what “Edge” means
Over the past decade, edge has mostly been contemplated as a discrete set of platform features bundled together and deployed physically across a geographically distributed space to serve one-to-many business application needs. This could take the form of a regional point-of-presence (POP) or an “on-prem” deployed solution or other similar permutations.
Is this still the right working definition for edge and the right deployment paradigm to solve the problem?
We think the answer has shifted to “no”, and that the new paradigm is one of layers of computing primitives tailored towards the business problem being solved. This answer is both empowering (there is no one-size-fits-all) and challenging (there is no one-size-fits-all—you have design work to do!).
So if you do need edge, here’s how to think about the shape of it. Logically speaking, the layers worth naming:
- Mid-edge: A regional tier that serves many downstream sites. Two distinct roles worth naming separately:
- Customer-facing mid-edge: workloads that need lower latency than cloud but don’t need to live in every deployed location. The “customer” is the end user; the mid-edge exists because cloud is too far away.
- Edge-supporting mid-edge: workloads that prop up the edge-edge tier—model-serving for locations that can’t run the model locally, software distribution staging, telemetry aggregation before cloud egress, fallback compute for degradation events, regional caches of reference data. The “customer” is your own distributed edge fleet.
- Edge-edge: Site-level general-purpose compute (a box or small rack) at the business location. The “customer” is business applications.
- IoT-edge: The device-fleet aggregation layer. A gateway sitting between many small physical devices and the rest of the stack, handling protocol translation, local filtering, and buffering. The “customer” is devices.
- Sensor-edge: Compute on or immediately adjacent to the device itself, such as a sensor or smart camera. The smallest footprint in the stack.
This array of edge deployment types can be designed to work in concert, yielding a set of technical capabilities that effectively support the business problem in front of you.
Frame your edge solution
How durable does your edge solution really need to be? We have observed that successful edge projects often build less durable solutions that are easier to operate but still meet business needs. What features do you need? Remember that every feature you add is future maintenance cost.
Do you really need distributed storage? Do you need to guarantee persistence? Do you need a clustered, HA solution?
For a strong architect or engineer, some tradeoffs can feel almost embarrassing after working on cloud solutions for a decade, but it’s not embarrassing when the solution still works in production 10 years later.
Be honest about your topology
One lesson a few of us share is letting the words on the slide get ahead of the architecture on the floor. A “data mesh” that is really a hub-and-spoke model, or “microservices” that are really a single logical center with every spoke pointed at it, will not behave like the thing on the label once it meets scale. Calling it a mesh does not make it distributed, and bolting a streaming bus onto a centralized design late in the game does not turn it into one either. The topology you actually build, not the name you give it, is what echoes. Draw the real one, and pressure-test it against the scale you expect.
Plan for Local AI
Speaking of planning for what is ahead, any solution that is starting in 2026 should immediately contemplate Local AI or “Edge AI”. Even a year ago, local AI was a “someday” consideration. No more.
This has meaningful impacts: hardware footprint, accelerator strategy, and more. As we have written about previously, there is a lot of exciting work in this space—from smaller-parameter large language models (LLMs) to domain-specific small language models (SLMs) to model-and-weights-on-chip or Analog Processing Units (APUs).2 Our 2026 prediction theme of “Miniaturization” continues with hardware as well, though the current climate makes the proposition expensive at the least.
There is not a clear right or wrong path today. Edge architects will have to design for outcomes that produce business value while managing cost and capability.
If your edge plan doesn’t have a local AI story, you may have a 2019 edge plan, not a 2026 one.
Act 2: Lock the Foundations
Negotiate the non-negotiables on day one
Edge computing is no place for architectural idealism. It is an environment rich in tradeoff decisions that require judgement and realism anchored in experience. Architects lacking that experience are best off making decisions they and their organization can support, and learning the new skills from iteration.
These foundational constraints are precisely the decisions that echo loudest. The earlier you nail them down, the more freedom you have downstream and the less negative architectural echoes will reverberate in your future. Write these decisions down. There are elements of the edge that are costly to change and that can even require a fundamental reset. These are important to get as right as possible from the start.
These aren’t just decisions to make. They are decisions to get explicit agreement on. In a large organization, unspoken non-negotiables quietly diverge. Every stakeholder assumes they’ll get the version they want, and you wake up one day trying to build two incompatible systems at once. Take offline-capable versus connection-required as an example. You simply can’t have both, but if you never force the conversation, half your customers will assume one and half will assume the other, and you won’t find out until it’s too late and too expensive. Get the alignment first.
Here are some examples:
- Offline-capable, or connection-required?
- Data residency: what leaves the box and what stays there?
- Team composition: what can you realistically support?
- Security baseline: what is the minimum floor?
- Day-2 ownership: who funds, staffs, and operates this after the launch event, and is that commitment real before you start?
- Organizational commitment of time to refactor and rework the results of hasty decisions made under pressure.
Ambiguity in these areas is the key indicator of negative long-term architectural echoes.
You don’t have to know everything before you start. You shouldn’t. But there are some things you must know and must get right before starting to scale.
The day-2 line above deserves its own warning, because it is where good edge work most often goes to die. Non-technical stakeholders tend to treat a working platform as a kind of perpetual motion device that simply runs itself once it boots, when in truth it is closer to a well-tended garden than a toaster that you “just plug-in”—something that has to be fed and maintained to keep bearing fruit. A successful demonstration with no funded path forward is not a milestone, it is a dead end, and a launch with no named owner for operations is a slow-motion liability. Decide who owns day two, and then fund it before you celebrate the first successful platform launch party.
Hardware is fungible. Invest in the layers that are not.
Many of us labored over certain design decisions for a long time before getting started with the work—hardware in particular. Concerns of size and form factor and capability required dominated, filled with opinions and slow to make decisions.
The reality is that hardware is not the right place to start. Most of us have worked across many hardware platforms over our careers. Hardware always changes. Business abstractions and platform abstractions are the more durable bet. When getting started, worry less about picking the perfect hardware and more about getting the platforms and services up and running on something.
A telco-style smart cities lens helped us early—but it also anchored us on “lots of little bespoke boxes.” That world didn’t materialize the way we thought it would. The reality is that mini-datacenter patterns won: VMs, larger machines, orchestration, containers. Way more “small datacenter at the edge” than “many tiny boxes.”
So treat hardware as fungible. But—and this is the inverse lesson—go deep on the things that are genuinely hard to change later:
- TPM, secure boot, attestation
- Base plane management
- A/B slice booting (you will regret not having this)
- Edge-native OSes (Canonical, EVE, etc.)—pick well
- Security primitives in general
These low-level choices are exactly the ones that echo the longest. The most banal decision, like an NTP server you provisioned across every location and never refreshed, can drift three seconds out of true twenty years later and become a problem you pay for thousands of times over. Form factor is fungible. Cryptographic identity, boot integrity, and the update mechanism are not.
Prototype the patterns. Don’t whiteboard them.
Rather than trying to decide in advance what will work, build 2–3 hardware patterns and see what holds up under real workloads. The most banal choices leave the largest tech debt, and poor hardware partitioning strategies do not fix themselves. The unglamorous decisions—including drive sizing, partition layout, and filesystem choice—are exactly the ones that calcify and that you cannot undo without a full re-iteration.
Prototyping cost is lower than deciding cost. Build the patterns through iteration. Pick the survivors.
We have watched teams burn months on academic debates. Will this service scale? Will this pattern hold at fleet size? Which database engine is the right one? Everyone brings their favorite flavor to the table and nothing converges.
It is wildly easy in 2026 to end this. Spin up 2,000 instances of the thing in the cloud, run your real workload, and watch what actually holds up. One team we know broke a multi-month logjam in about three weeks this way. “This one scales, this one doesn’t, here are the friction points, done.” Cloud is your scale-test environment. Settle the debate empirically, then move to prod.
Don’t whiteboard what you can benchmark.
Act 3: Execute the Flywheel
Manual first. Delete. Simplify. Accelerate. Automate.
The first thing you should do once you have a sense of your design is do things manually. This manual effort gets you painfully close to the details and teaches the invaluable lesson about how things are really going to work. More than one of us did the very first cluster entirely by hand, logging into each node in turn and pushing every certificate by hand, precisely because the pain is the teacher and there is no substitute for this.
Whether this period is 4 weeks or 4 months, embrace the process. Prove your assumptions true and learn where you are wrong.
Elon Musk has an “algorithm” he pushes his companies to operate by:
- Make your requirements less dumb.
- Try hard to delete the part or process (the best part is no part).
- Simplify.
- Accelerate.
- Automate.
There is a lot of wisdom in this approach, whether you’re building a reusable rocket or an edge system. We often observe teams (and ourselves) attempting to automate too early, thus automating bad or unnecessary processes, systematizing complexities instead of removing them, and automating the wrong things.
Elon’s process is a good guide. Do the hard work to understand, think, and simplify first. Then get the flywheel going. Finally, invest in automation.
If you haven’t yet done it by hand, you don’t yet know what to automate.
Run the cadence, buy down the risk, not the management plan
A clean-sheet edge effort lives or dies on its day-to-day operating rhythm, and a precanned plan of action and milestones is close to meaningless, because no such plan survives first contact. The situation changes the moment you begin. The impediments you wrote down on Monday are not the impediments you face on Wednesday, and a team that is genuinely moving will outrun a static milestone chart within days. The honest steering mechanism is a short daily standup run on radical candor, where each person answers the same three questions in turn: what did you do yesterday, what are you doing today, and what are the impediments to progress. A small release valve helps too, such as closing with one project-adjacent piece of discovered tech someone simply found interesting, to keep the pressure survivable.
A few of us think about running a team under pressure the way you would play speed chess. Own the center of the board, make sure everybody has a job, and advance your pawns. Do this on the conviction that it is the everyday moves and the smallest pieces—which on a team are your most junior people—that quietly decide the outcome rather than the dramatic plays. In that spirit, pointing a forward element, even relatively junior engineers, at discovery and framing ahead of the core build is one of the cheapest ways to map the unknowns and buy down the risk of whatever is coming next in the architecture, as long as scouting the terrain is not confused with resting load-bearing infrastructure on shoulders that are not ready for it yet. When the chessboard analogy runs out of room, reach for a second frame: a strong team is a complementary Dungeons and Dragons party rather than a set of interchangeable resources, so you take care of every class on the roster, the Thief-Rogue most of all, the scrappy specialist who picks the locks no one else can with the “knack” to fix the Error 500s, and you remember that you are all on one long campaign whose whole purpose is to slay the dragons of scale.
Ship it, rip it, ship it again. Get the flywheel spinning.
Waterfall projects are especially seductive in platforms and infrastructure. Do not fall prey to the siren’s song.
If you are starting your edge platform in 2026, ship a first iteration in 2–4 weeks and get real users to use it. Ship. Rip. Ship again. This is the way. As we have all heard countless times, perfect is the enemy of good. The vehicle to the proper solution is found in the first-hand experience of your users with your product.
One way we encourage doing this is by getting sandbox environments and test harnesses into the hands of developers as early as possible. Leading organizations have sandbox environments so that developers can learn how the platform works, how to think about their applications, and initiate the feedback cycles. Do this as early as possible. We cannot say enough that this experience cannot be gained through architecture diagrams or PowerPoint presentations. Evangelism, adoption, and feedback come through hands-on experience. Most of the Edge Monsters felt we embraced this too late. Do it early.
Hardware demands its own version of this test environment. A real hardware-in-the-loop test harness—the kind of rig that lets you remotely cut and restore power through relays, bounce a box, and prove that it boots cleanly through legacy BIOS, PXE, and UEFI alike—pays for itself many times over, because getting the boot and provisioning path right early is the difference between a calm later iteration and a painful rebuild under deadline. Be warned that you may have to build much of this supporting infrastructure yourself, sometimes acting as your own IT department when the legacy data center environment hands you little more than lights, power, and an empty rack. Budget for that work rather than discovering it the hard way.
One pattern we have seen success with is “self-destructing cloud environments” that spin up an edge-like environment, run for N days, and then tear themselves down unless extended.
You may not know exactly what to do. Start shipping, ask Claude, try things, get the “crappy” product in people’s hands, don’t do anything catastrophic, learn, and iterate fast. That is the way to find “product-market fit” and a true minimal viable product for your edge.
Your platform is only as strong as the developers who build on it. Expose them early and often.
Get product involved early. And let someone own it.
If there’s one thing many of us would do differently, it’s this: we added the product perspective too late. Engineering-led platforms drift from customer reality. Product and engineering working together from the start is what clarifies the customer profile, the mission, and the non-negotiables we’ve discussed so far in this post.
There are two traps to avoid here:
- The first is the belief that you can buy your way out of challenges. “Money doesn’t solve engineering problems.” The corollary is to resist asking for more money than the work needs, because an oversized budget invites an oversized scope and a team too large to move. Further, throwing more people at a platform usually just converts engineering work into coordination overhead; past a certain point, too much labor means all coordination and no progress.
- The second is distributed ownership. When a platform is everyone’s problem, it’s nobody’s, and nothing gets done. Someone has to own it.
Bring the broader organization together early. The platform doesn’t win on its own technical merits. It wins because the people who’d build on it had a hand in shaping it.
Conclusion
Starting over gives a chance to return to first principles and to approach edge computing as a potential solution to a set of business problems. There are no silver bullets. The goal is to make decisions today that return to first principles, consider the long-term architectural echoes, and strive for absolute simplicity.
It is worth ending where we began. Technology is rarely the thing that decides whether an edge program succeeds. Getting a hard project done, in a company or anywhere else, tends to rest on four legs of a stool, and engineering is only one of them.
- The first is genuine, unwavering resolve from leadership.
- The second is a funding and procurement path that can actually move, rather than one that admires the idea and never buys anything.
- The third is a security posture that is willing to say “yes, if” instead of a reflexive no, because a capability that cannot be accredited is a capability that never ships.
- The fourth is the engineering itself. Take any one leg away, and the stool falls over.
Plan for all four legs, design for the echoes that make one of the legs slightly shorter, and keep it simple.
The Edge Monsters: Jim Beyers, Colin Breck, Brian Chambers, Mike Ensor, Tilly Gilbert, Michael Henry, Michael Maxey, Chris Milliet, Erik Nordmark, Joe Pearson, Jim Teal, & Dillon TenBrink.
Footnotes
1 Thanks to Brad Loomis for the great question we answered in this post.
2 Shoutout to friend of the Edge Monsters Chris Woods for surfacing some of the model-on-chip and analog computing thoughts.
Want to go deeper? Join the Edge Monsters community.
Be sure to subscribe to updates and follow us on LinkedIn.
