Understand the Health of Your Custom Software

The Scene: 18 Months Later It started with fanfare. Board approval. A standing ovation at the quarterly all-hands. The CEO stood on stage and announced a transformative initiative that would unify data across the organization, unlock new insights, and finally give the company a competitive edge it had been chasing for years. "The future," they said, "is finally here." Fast forward 18 months. The initiative isn't dead. It's worse than dead. It's in limbo—that strange purgatory where projects go when no one has the courage to kill them and no one has the capacity to save them. The vendor you hired with such high hopes? They're still billing you. Their Jira board shows "progress." But when you ask your team what's actually changed, you get shrugs. A few reports landed in someone's inbox—basically the same Excel spreadsheets you've always had, just with a different logo in the corner. Meanwhile, the business has moved on. Processes have shifted. The careful requirements documents from 18 months ago now describe a reality that no longer exists. Your customers are waiting for features that never arrive. Your competitors are eating your lunch. And somewhere in the engineering department, a team of talented people is quietly dying inside, one pointless sprint at a time. What happened? Was it the engineers' fault? Did they fail to understand the problem? Was the product owner incompetent? Did the business simply stop caring? Was it a lack of prioritization? I've walked into more stalled initiatives than I can count. As the founder of Datably, I've made a career of resuscitating software projects that should have been successes but somehow became sinkholes. And after years of doing this, I can tell you with certainty: The answers are never simple. But they are predictable. Here's what actually kills enterprise software initiatives—and what you can do about it. Part I: The Root Causes 1. The Executive Paradox: "This Is a Priority, But Don't Ask Me for Anything" Every stalled initiative begins with the same contradiction. The executive suite declares the project critical. It's in the strategic plan. It's on the board's radar. The CEO mentions it in every all-hands. On paper, this initiative has never been more important. But when the IT director says, "Great—I need you to take something off my plate so I can focus on this," the conversation gets awkward. Because here's the truth your IT team won't say to your face: They're already underwater. They're running 40 initiatives with a team built for 10. They're integrating acquisitions, onboarding new employees, keeping the lights on, and fighting fires that started before you joined the company. They've seen initiatives like yours come and go for years. They've watched the parade of vendors parade through, each one promising transformation, each one leaving behind a trail of half-finished code and unmet expectations. They're not cynical because they're bad employees. They're cynical because they've lived this movie before. They know how it ends. So when you announce your grand initiative, here's what they hear: "Another thing. Cool." And then they keep doing exactly what they were doing before, because those things are actually urgent. Those things have real consequences if they fail. Your initiative? It's important, sure. But important things can wait. Urgent things can't. The executive paradox, in a nutshell: You say it's a priority, but you won't prioritize it. You won't fund the headcount. You won't remove obstacles. You won't personally inspect progress. You just... assume it'll happen. Software doesn't work that way. The "Buy Software, Not People" Fallacy Here's a variation on the same theme: Executives look at a problem and think, "There must be a tool for this." They buy Snowflake. They buy Salesforce. They buy some AI platform that promises to "revolutionize" their business with zero human intervention. And then they move on to the next thing. But data doesn't transform itself. AI doesn't build itself. Software is a tool, not a solution. The solution comes from people—from the architects who design the system, the product managers who understand the users, the engineers who write the code, the DevOps professionals who keep it running. You can buy all the tools in the world. If you don't invest in the people, you've bought very expensive paperweights. The Inspection Gap There's a management principle that applies here: You get what you inspect, not what you expect. If your initiative is truly a priority, it should appear in every board meeting. Every executive staff meeting. Every one-on-one with the leaders responsible for delivering it. The question shouldn't be "How's the project going?" once a quarter. It should be "What did we ship this week?" every single week. When you inspect, you signal importance. When you don't, you signal that this is just another thing on the pile—and the pile always wins. 2. The Myopia Trap: Building for the Loudest Voice Here's a scenario I've seen play out in dozens of organizations: You have four business units. All of them are supposed to benefit from this new software initiative. But one of them—let's call them the "revenue kings"—has the ear of the IT team. Maybe they're the biggest moneymaker. Maybe their VP is golf buddies with the CIO. Maybe they're just the loudest complainers. Whatever the reason, they drive the requirements. The software gets built. It works great for the revenue kings. Everyone else? They get whatever's left over. But here's the question no one asks: What if the revenue kings aren't the ones who need the software most? What if the team that's struggling—the one that could 10x their impact with the right tools—is the one no one's listening to? When you let the loudest voice drive the bus, you end up with software that solves the wrong problems. And when you finally roll it out to the rest of the organization, you get the response every software team dreads: "This doesn't work for me." The 5'2" Car Designer Problem There's a classic analogy I use to explain this. Imagine you're designing a car for the mass market. You bring in a focus group, and one participant—a 5'2" individual—is very opinionated. They want the seat positioned perfectly for short drivers. They want the pedals adjusted just so. They're loud, they're persistent, and they have the ear of the design team. So you build the car for a 5'2" driver. Then a 6'1" customer tries to get in. They can't fit. They are squished up against the headliner. They hate everything about it. That's what happens when you let one voice—no matter how loud—dictate software design for an entire organization. You build something that works for that one person (or that one business unit) and fails for everyone else. The Unrepresentative Power User Even worse: sometimes the loudest voice isn't even representative of their own team. It's just one person with strong opinions and a lot of influence. They'll tell you, "Solve my problems. Don't worry about everyone else's." But software isn't about solving one person's problems. It's about solving everyone's problems, collectively. It's about finding the common ground, the shared workflows, the patterns that work across the organization. When you let the unrepresentative power user drive the bus, you end up with software that reflects their idiosyncrasies—and fails everyone else. 3. When IT Runs the Show (And Business Takes a Backseat) This is one of the most painful dynamics I see. A business leader says, "We need a system to handle approvals for quotes." They hand it over to IT. IT does what IT does best: they dive into the technical problem. They design a beautiful system. Elegant architecture. Clean code. They show it to the business users three months later. The business users stare at it for a moment. Then they say: "That's great. But it doesn't follow our actual workflow." What went wrong? The IT team is full of brilliant people who love solving problems. They love organizing, optimizing, writing elegant code. They're mission-oriented: give them requirements, and they'll build you something beautiful. But here's the thing: They're not business experts. They don't live in the day-to-day reality of the quote approval process. They don't know the exceptions, the edge cases, the unwritten rules that everyone just knows. They hear "approval workflow" and build a generic approval workflow. The business users needed something specific to their industry, their customers, their unique way of operating. So now you have a problem. The IT team built exactly what you asked for. But what you asked for wasn't what you needed. So you go back for another round. And another. And another. By the time you're done, you've rebuilt the same system three times. Your costs have tripled. Your IT team is frustrated because they keep rewriting instead of building. Your business users are frustrated because they keep getting things that don't work. And your timeline? Completely blown. The Root Cause: No Business Driver The real problem is that the business wasn't driving the software. IT was. And IT, no matter how talented, can't read minds. They can't intuit the nuances of a process they don't live every day. You need someone whose job is to bridge that gap. Someone who understands business and technology. Someone who can sit with users, watch them work, ask the right questions, and translate their needs into requirements that developers can actually build. That's what a product manager does. If you don't have one—or if your product manager is buried in other priorities—you're flying blind. The "I Know Better" Trap Sometimes it's worse. Sometimes the IT team genuinely believes they know better than the users. The users try to explain a complex process, stumbling over terminology, struggling to articulate what they need. The developer nods along, says "I got it," and builds something completely different—because they've already decided what the real solution should be. Or they hear about exceptions—the 10% of cases that don't fit the standard flow—and decide, "We'll just handle the 90%. That's good enough." But here's what they don't understand: For the business user, that 10% matters. If they have to think about whether a transaction qualifies for the software every single time, adoption plummets. They'll go back to their spreadsheets, because at least the spreadsheets don't make them think. 4. The Faster Horse Problem There's a famous quote attributed to Henry Ford: "If I had asked people what they wanted, they would have said faster horses." This is the eternal tension in software development. Users know their current process. They know its pain points. They know what would make it slightly better. What they don't know is what a fundamentally different process could look like. So when executives say, "We're not just improving the old way—we're reimagining the whole thing," users push back. They don't want reimagined. They want their current process, just a little faster. Just a little less painful. The executive sees a car. The user wants a faster horse. This isn't users being difficult. It's humans being human. Change is hard. New processes are scary. And when you're the one whose daily work is about to be upended, "faster horse" sounds a lot safer than "car." The problem is when no one bridges that gap. When executives don't take the time to paint the picture, to help users understand why the car is better, to guide them through the transition. Instead, they just push the car down the throats of people who wanted faster horses. The result? Resistance. Low adoption. Another stalled initiative. Part II: How to Spot a Stalled Initiative (Before It's Too Late) If you're a leader reading this and wondering, "Is this happening to me?" here's what to look for. On the Jira Board Open your project management tool. What do you see? If you have a team of five people and 45 initiatives all marked "in progress," you have a problem. A healthy team can handle maybe four or five active initiatives at once. Everything else should be in the backlog, waiting its turn. Look for initiatives with start dates from 18 months ago that are still "in progress." Look for tickets that have been "almost done" for weeks. Look for the word "priority" attached to everything—because if everything's a priority, nothing is. In Your Developers' Faces Talk to your engineering team. Not about status—about how they feel. Do they seem resigned? Do they roll their eyes when you mention the initiative? Do they say things like, "Yeah, we'll get to it eventually," with the flat affect of someone who's heard this before? Developers want to finish things. They want to ship. They want to see users delight in what they've built. When they're constantly interrupted, constantly reprioritized, constantly moved from one half-finished project to another, it kills something in them. They stop caring. They stop trying. If your team seems burned out, you're probably stalling. In Your Business Users' Complaints Talk to the people who are supposed to use this software. Do they feel heard? Do they believe that if they tell you what they need, anything will actually happen? Listen to the nature of their complaints. Are they talking about the big picture, or are they fixated on one tiny thing that's been annoying them for months? When users obsess over small details, it's often because they've given up on the larger vision. They're fighting the battles they think they can win. In Your Own Gut Finally, check in with yourself. When you think about this initiative, do you feel excitement—or resignation? Do you believe it's going to happen, or are you already making peace with failure? If you're resigned, your team knows it. And if the leader doesn't believe, no one will. Part III: The Hidden Cost of Stall Let's talk about what's really at stake here. I've walked into companies where the stalled initiative wasn't just an annoyance—it was an existential threat. Where the software was their main product, and it was losing customers. Where every day of delay meant real revenue walking out the door. Where they didn't have the money to start over, but they also couldn't afford to keep going the way they were. Those conversations are brutal. But the cost isn't just financial. There's a human cost too. I've seen teams miss weddings, birthdays, important family events—all to try to ship software that ultimately failed. I've seen talented developers burn out and leave the industry entirely because they couldn't take one more pointless sprint. I've seen business users give up on technology altogether, retreating to their spreadsheets and sticky notes, convinced that software will never work for them. That's not just a failed project. That's a failed culture. And it takes years to rebuild. Part IV: The Datably Approach—How We Get Momentum Back So what do we do when we walk into a stalled initiative? Step One: Understand First, Build Second We don't start with code. We never start with code. We start by understanding what you're actually trying to accomplish. Not the features. Not the requirements. The strategy. What revenue are you trying to protect? What growth are you trying to unlock? What decisions do you need to make better, faster, smarter? Until we understand that, everything else is just guessing. Step Two: Fix the Process, Then the Software Here's a truth that surprises a lot of leaders: Software is a catalyst, not a solution. If you have bad processes and you put them into software, you now have fast bad processes. The software doesn't fix anything—it just makes the dysfunction happen faster. So before we write a line of code, we help you examine your processes. Are they working? Are the business units aligned? Is there a unified vision, or is everyone pulling in different directions? Sometimes the most valuable thing we do is help you not build software—because what you really need is a process change, not a new tool. Step Three: Focus Remember that Jira board with 45 initiatives? We help you pick three. Not because the other 42 don't matter. Because if you try to do everything at once, you'll do nothing at all. We help you identify the few things that will actually move the ball forward, and we focus on those until they're done. Step Four: Treat Software as an Investment, Not an Expense Every feature we build has to answer three questions: What problem are we solving? What's our proposed solution? What's the expected return on investment? If you can't tell me the ROI, we're not building it. This changes everything. Suddenly, every feature is accountable. Every line of code has a purpose. And at the end of the year, you can look back and say, "This feature brought in X revenue. That feature saved Y costs. This one improved customer retention by Z percent." Software stops being a black hole and starts being what it should have been all along: a strategic asset. Step Five: Design Before Code Before we write a single line of code, we prototype. We wireframe. We show you something clickable, something you can react to, something you can show to your users. Then we iterate. And iterate. And iterate again. Only when the design is right—when you've seen it, touched it, and confirmed that it solves the real problem—do we start building. This saves enormous time and money. Because changing a design is cheap. Changing code is expensive. And changing code after it's already deployed? That's where initiatives go to die. Step Six: The Momentum Moment Here's my favorite part of the process. The first time we ship something—even something small—that users have been asking for months... something shifts. The energy changes. Users get excited. Developers feel validated. Leaders start believing again. I've seen it happen a hundred times. A team that was resigned, cynical, ready to give up suddenly has hope. They start suggesting new ideas. They start caring again. They start believing that maybe this time will be different. That's the moment momentum returns. And once you have momentum, everything gets easier. Part V: Three Questions to Ask Yourself Right Now If you're worried your initiative might be stalling, here's a quick diagnostic you can run today. Question One: What's Actually on Your Board? Open your project management tool. Look at everything marked "in progress." If you had to pick three—just three—that would make the biggest difference to your business, what would they be? Now ask yourself: Why are the other 42 still there? Who's protecting them? Who's insisting they stay active? And are those reasons good enough to justify the drag they're creating on your team? Question Two: What's the Sentiment? Talk to your developers. Talk to your business users. Talk to your leaders. Ask them one question: "How do you really feel about this project?" Listen for resignation. Listen for frustration. Listen for the quiet hopelessness of people who've given up. If you hear it, you have your answer. Question Three: Is There a Unifying Vision? Who owns this initiative? Not in title—in reality. Who wakes up every morning thinking about how to make it succeed? Who has the authority to make decisions? Who's responsible for the outcome? If the answer is "no one" or "everyone" or "I'm not sure," you've found your problem. Initiatives need champions. They need someone whose primary job is to drive them forward. If that person doesn't exist—or if they're pulled in too many directions—the initiative will stall every time. The Invitation Here's the thing about stalled initiatives: they're not hopeless. I've seen too many come back from the brink to believe that. But they do need something different. They need fresh eyes. They need someone who hasn't been living in the dysfunction, who can ask the questions no one's asking, who can see the patterns no one's seeing. They need a partner who brings perspective, process, and a relentless focus on outcomes. That's what Datably does. We don't just write code. We partner with leaders like you to rescue initiatives that matter—and to build new ones that never stall in the first place. If you're ready to have a conversation about your stalled initiative—or about how to keep your next one from stalling—I'd love to talk. No pressure. No sales pitch. Just a conversation between people who care about building software that actually works. Because the truth is, your initiative matters. Your team matters. Your customers matter. And you deserve software that delivers on its promise. Let's make it happen.

What started as a rescue mission has evolved into a true strategic partnership. By taking over the development from a single, overwhelmed contractor, we didn't just fix a checkout flow—we unblocked an entire business.