Before You Build That Admin Tool

"We need to make changes ourselves because waiting on engineering is too slow and we're losing money."

Tell me if this sounds familiar: a department gets signals from the market, needs to adjust pricing or promotions or workflows, and the engineering backlog feels like it's in the way. Self-service tooling seems like the obvious answer: build an admin interface so stakeholders can make changes themselves without being bottlenecked by sprint cycles or release schedules.

The instinct isn't wrong. In fact, whole companies are built around this premise. The business should move at the speed of learning. The question is whether building self-service infrastructure actually gets you there, or whether you're solving the wrong problem in an expensive, fragile way.

What You're Actually Betting On

When you commit to building self-service tooling, you're making several bets that often go unexamined.

You're betting on stability. You're codifying current business rules, data structures, and workflows into a system. You're declaring that these assumptions have staying power and that the way things work today is roughly how they'll work for the foreseeable future.

Here's what that might look like in practice though: You build a promo code system where users can set percentage discounts. Clean, simple, empowering. Six months later, Marketing needs buy-one-get-one offers. Then tiered discounts based on cart value. Then conditional logic based on customer segments. Then exclusions for certain product categories. Each addition makes the system more brittle and the UI more complex. What started as "empower Marketing to move fast" becomes "engineering is constantly patching the self-service tool instead of just making the changes directly." The original assumptions didn't hold, and now you have grafted fixes onto a system that wasn't designed for this complexity.

You're betting on volume. The ROI only works if changes happen frequently enough to justify the build and maintenance costs. More often than not, our teams and stakeholders overestimate this. "We need to make changes daily" sounds right until you factor in approval processes, compliance requirements, validation steps, and coordination overhead. In practice, those daily changes become weekly or monthly. The breakeven point is further out than most people think, and it only arrives if actual usage meets the forecast.

You're betting the organization is ready. Self-service tools work best when you have strong operational maturity: monitoring to catch problems, incident response to handle failures, rollback capabilities to undo mistakes, clear ownership frameworks for who's responsible when things go wrong. Without these, you're just creating more complex ways to fail. If someone misconfigures a promotion that costs the company money, who owns that? Engineering built the system, but Marketing made the change. This responsibility ambiguity rarely gets resolved upfront and creates organizational friction later.

What You're Really Signing Up For

The pitch for self-service is usually framed as "we'll save engineering time." But in the end, that's likely not what actually happens. You're not eliminating engineering work… you're shifting it.

Instead of making changes, engineering is now supporting change-makers who can't figure out the interface, debugging production issues caused by configurations they didn't know about, cleaning up bad data from user mistakes, building documentation and training materials and guardrails, and maintaining the self-service system itself as requirements evolve.

Is the shift worth it? Sure, sometimes. Often it's not. But the conversation should be "we'll shift engineering from making changes to supporting change-makers" not "we'll save engineering time." That framing forces you to evaluate the trade honestly.

There's another cost that's harder to see upfront: assumption lock-in. Once users get accustomed to making changes with no lead time, they expect that to continue. When they need something the system doesn't support, those requests come with urgency attached because they're used to instant gratification and now they can't have it. But these new requirements can likely represent fundamental changes to how the system works, affecting data structures and business logic across everything the system supports. If the original engineers are gone or the architecture isn't well-documented or the time pressure dictates the fix, you get quick patches instead of proper solutions. Technical debt accumulates fast because the pressure is to restore the self-service capability, not to fix the underlying design.

Then there's testing and validation. When changes happen through code, you have CI/CD pipelines, automated tests, PR reviews, deployment validation. When changes happen through a UI, unless you've built all that infrastructure around it (which significantly increases the investment), you lose those safety nets. Configuration changes in production bypass the quality controls that protect your system. Non-production likely doesn’t stay in sync with what’s live in the product. Building those controls for self-service requires significant engineering effort that often gets underestimated in the initial scoping.

Designing for Yesterday's Workflow

Right now you're building for humans to click buttons in a UI. But think about where this is headed.

Configuration changes will increasingly be driven by ML models optimizing in real-time, made by AI agents responding to business signals, integrated programmatically with other systems and workflows. Admin UIs aren’t necessarily the right interfaces for that future. They put an abstraction layer between you and programmatic control. An AI agent can generate and modify code, submit PRs, work with APIs, etc. Navigating a bespoke admin panel? Much harder, if not impossible without significant additional tooling.

If you believe automation is coming to this space, and it likely is, building UI-first tooling is designing for yesterday's workflow. APIs and version-controlled config files could protect “future you” better because they work for both humans and machines. They're more flexible, more auditable, and easier to evolve as your understanding of the problem space matures.

Where’s the Actual Bottleneck?

The conversation shouldn't start with "should we build self-service?" It should start with "where is the actual bottleneck and what's the right way to address it?"

There's a principle from The Goal, Eliyahu Goldratt's book about manufacturing optimization, that applies here: "I say an hour lost at a bottleneck is an hour out of the entire system. I say an hour saved at a non-bottleneck is worthless. Bottlenecks govern both throughput and inventory." The book is about factory throughput, but the insight translates to software delivery: optimize the constraint, not everything else.

Is engineering capacity actually the bottleneck? Or is it something else entirely?

Maybe it's a slow SDLC (without effective CI/CD) that makes changes take days instead of minutes. Maybe it's process overhead (approvals, validation steps, compliance checks) that would slow down self-service changes just as much as engineering-driven ones. Maybe it's a lack of monitoring and validation that makes any change risky, regardless of who makes it. Maybe it's poor communication between business and engineering about priorities and urgency, so important changes sit in the backlog while less important work gets done.

If you can make your deployment pipeline fast enough and safe enough, the cost of engineering-made changes approaches zero. Ten-minute deployments with automated validation and easy rollbacks change the equation entirely. At that point, self-service stops being a time-saver and becomes additional infrastructure to secure and maintain. You've added complexity without removing the constraint.

You’ve Got Options

Before committing to full self-service, consider options that give you speed without the fragility:

• Version-controlled config files that stakeholders can edit via pull request, with validation in CI. Non-engineers can propose changes; the pipeline ensures they're safe. You get auditability, testability, and the ability to evolve assumptions without grafted-on fixes.
• Buy instead of build. Feature flag platforms, CMS tools, workflow systems that already handle the edge cases you haven't thought of yet. These come with security, auditability, and operational maturity baked in. The cost might seem high compared to "just build it ourselves," but factor in long-term maintenance and support burden.
• Hybrid models where self-service generates a pull request instead of making direct production changes. You get the empowerment and speed without losing safety and review. Users feel unblocked, engineering maintains quality controls, and you preserve the ability to evolve the system as assumptions change.

Process improvements can make engineering-driven changes faster rather than trying to bypass them. If the real bottleneck is communication or prioritization, building self-service infrastructure doesn't solve that, it just moves the friction somewhere else.

When Self-Service Might Actually Make Sense

I'm not saying self-service tools are always the wrong solution. They can work when you have a high volume of changes that are truly (and persistently) frequent, not aspirationally frequent. Low complexity where you're changing simple values, not logic or workflows. Low consequence of errors where mistakes are annoying, not costly or catastrophic. Low expertise required where the changes don't need deep domain knowledge. Low risk of user error where mistakes are obvious and easy to catch. And organizational maturity with strong monitoring, incident response, clear ownership, and operational discipline.

Even then, you're betting that current assumptions will hold, volume stays high enough to justify ongoing maintenance, users won't need capabilities beyond what you've built, and the organization can handle distributed responsibility for changes.

Most teams don't honestly map their situation against these dimensions before building. The instinct to "unblock people" overrides the harder questions about whether this is the right tool for the problem. It feels good to say yes to empowerment. It's harder to ask whether you're creating more problems than you're solving.

Find the Right Way to Move Fast

Self-service tools aren't speed solutions, they're infrastructure investments that shift costs rather than eliminate them. They require stable requirements, sustained high volume, organizational maturity, and acceptance of ongoing support burden.

Before building self-service infrastructure, ask: What's the actual bottleneck preventing speed? Can we make engineering changes fast and safe enough that self-service becomes unnecessary? Are our assumptions stable enough to codify into a system? Do we have the operational maturity to handle distributed responsibility for changes? What's the real volume and frequency of changes once we factor in actual process overhead, not the aspirational version?

The instinct to move at the speed of business is right. Building self-service infrastructure is often the expensive, fragile answer to that instinct. Make it easier and safer for engineering to make changes quickly instead. That's oftentimes the better investment (and is a deeper, more systemic fix), and it positions you better for a future where changes are increasingly automated rather than manually configured through UIs.