Custom Software & Tools

My team has clear pain points but I cannot articulate what software would fix them. How do I figure out what to build?

This is one of the most common situations we walk into, and it is also one of the most important to handle properly. The instinct, when you can see your team struggling but cannot quite name the solution, is to either describe the pain to a developer and hope they figure it out, or to start looking at software products and try to find one that matches the shape of the problem. Both paths lead to the same place, which is a tool that solves something close to but not actually the issue, and a team that quietly goes back to the old way of working within a few months.

The reason this happens is that pain points are usually symptoms, not causes. Your sales team complaining that they spend half their day in spreadsheets is the symptom. The cause might be that your CRM does not capture the data they need, or that quote generation requires too many manual touchpoints, or that handoffs between sales and operations happen through email instead of through a system that holds the context. Each of those root causes calls for a different solution. The wrong diagnosis produces software that addresses the visible frustration without removing the underlying friction.

Figuring out what to build, properly, requires a process that starts upstream of the software conversation. You have to map the work as it actually happens, not as the org chart suggests it does. You have to interview the people doing the work and identify the moments where they lose time, make errors, or do things twice. You have to look at where information is created, where it is needed, and where it has to be manually moved between the two. You have to understand the exceptions and edge cases, because real workflows are defined as much by the messy outliers as by the clean happy path. Only then can you have a sensible conversation about what to build.

For most operators, this is exactly the work that is impossible to do internally. Leadership does not have the time to sit with each team and trace the actual workflow. The people doing the work cannot easily articulate the gaps because they have normalized the workarounds. And no developer, no matter how skilled, can produce this kind of diagnosis from a one-hour scoping call. The discovery work has to be done by someone who can sit with the team, ask the right questions, see the patterns, and translate what they observe into a software specification that actually matches what the business needs.

This is the gap that we close. The conversation does not start with what we will build. It starts with what your team is actually trying to do, where it is going wrong, and what the right shape of the solution would be. Sometimes the answer is custom software. Sometimes it is a configuration change to a tool you already own. Sometimes it is a workflow redesign that does not need software at all. The point is that you do not have to know what to build before you bring in help. The figuring out is part of the work, and it is the part that decides whether the eventual build is worth the money.

If you can see the pain but cannot name the fix, you are not behind. You are at the start of the diagnosis, which is exactly where the work should start.

---

The software we use almost works, but we keep building workarounds around the gaps. When does it make sense to stop patching and build something custom?

The workarounds are the signal. When a team is exporting data into a spreadsheet to manipulate it because the tool cannot do what they need, or maintaining a parallel system in Notion or Airtable to track what the main software was supposed to track, or routinely sending data between tools by copying and pasting, the software is no longer serving the operation. It is being held in place by manual effort, and the cost of that manual effort is hidden because it shows up as time rather than as a line item.

The right way to think about the decision is to look at three things.

The first is the actual cost of the workarounds. Most leadership teams underestimate this by a lot. The five minutes a salesperson spends every day reformatting a report. The hour your operations lead spends every week reconciling data between two systems. The half-day someone loses every month chasing down information that should be visible at a glance. Multiply these by the number of people doing them, by the number of days they happen, by the loaded hourly cost of the people involved. The number that comes out the other side is almost always larger than anyone expected, and it is recurring. It does not stop until the underlying issue is resolved.

The second is the risk those workarounds carry. Manual data movement creates errors that compound silently. Spreadsheets become single points of failure tied to one person. Parallel systems drift out of sync with the source of truth. The work continues to happen, but the data the business is making decisions on is increasingly unreliable, and nobody knows where the discrepancies are. This kind of risk does not produce dramatic failures. It produces quiet, expensive degradation in the quality of decisions the business is making.

The third is what you are giving up. The team working around the limits of the current software is not building toward anything. They are running in place to keep things from getting worse. The strategic projects, the operational improvements, the work that would actually move the business forward, all of it is being deferred because too much capacity is spent patching. The opportunity cost is the part most operators never calculate, but it is often the largest piece of the equation.

When two or three of those three are weighing meaningfully on the operation, custom is almost always the better answer. Sometimes the right custom answer is to replace the existing tool. Sometimes it is to build a layer that sits between your tools and removes the manual work between them. Sometimes it is a small internal application that handles a specific workflow the available software was never designed for. The shape of the build is determined by the shape of the problem, but the decision to stop patching is usually the right one once the workarounds have hit a certain density.

What we tell clients in this position is that the question to ask is not “is custom software expensive.” It is “what is the existing situation costing me.” Once that number is real, the build is usually the cheaper option, even before you account for what becomes possible once the team is free of the workarounds.

The workarounds are the bill the business is already paying. Custom software is what you pay to stop paying it.

---

Our last custom build sat unused because the team kept going back to the old way. How do I make sure the next one actually gets adopted?

This is one of the most common and most expensive failure modes in custom software, and it is almost never a software problem. The build works. The features are there. The technical execution is sound. And the team uses it for two weeks, then quietly slides back to the spreadsheets, the workarounds, the muscle memory of how they were doing it before. Six months later, the software is technically live but operationally invisible.

The reason this happens is that the build was designed without the people who would have to live with it. Someone described the requirements. A developer built against those requirements. The team was given training when it shipped. None of those steps is wrong, but together they produce software that the team had no role in shaping, no sense of ownership over, and no real reason to trust over the process they already know how to make work.

Adoption is not a phase that happens at the end of a build. It is an outcome that depends on the design choices made at the start, the people involved during the work, and the change management that runs alongside the rollout. If any of those three is wrong, the software fails to land regardless of how good the technical work is.

The design choices have to fit the actual workflow. Not the workflow as it appears on a process diagram, but the one as the team actually performs it, including the exceptions, the informal handoffs, the small accommodations people make for each other. Software that ignores those realities forces the team to choose between using the tool correctly and getting their work done. They will pick getting their work done every time.

The people doing the work have to be involved in the design. Not consulted once at the start. Genuinely involved as the work takes shape, so they see how their input is reflected in the build, so they identify the wrong assumptions before they get baked into code, and so they arrive at launch already feeling like they helped create the thing. People do not abandon tools they helped design. They abandon tools that were imposed on them.

The change management has to run alongside the rollout, not after it. Training is the bare minimum, and it is not enough on its own. The team needs the support to ask questions, the patience to work through the inevitable rough edges, and the explicit permission from leadership to use the new system even when the old way would be faster in the short term. Without that frame, the team will rationally choose the path of least resistance, and the build will be the path of more resistance for several weeks until the muscle memory builds. Most rollouts give up before that point.

When we build custom software, adoption is treated as the actual deliverable. Code that runs is necessary, but it is not sufficient. The deliverable is a system that has become part of how your team works. That requires the design, the involvement, and the change management to all be done properly, and it requires the build partner to stay engaged through the period where the team is still moving from the old way to the new way.

If your last build sat unused, the cost is not just the money you spent. It is the loss of trust in the idea of custom software itself, which is the most expensive part. The next one has to be approached differently. The team has to be at the table. The rollout has to include the support that turns a launched system into an adopted one. And the partner running the build has to treat adoption as the success metric, not as something that someone else will worry about after the code ships.

---

I keep hearing custom builds should have AI baked in. Where does AI actually add value, and where is it being sold as a feature that does not earn its place?

This is a useful question to ask because the AI feature inflation in custom software right now is real. Every vendor pitch has AI in the deck. Every conference talk frames AI as the differentiator. Every developer wants to put a model behind something. The result is a lot of custom builds shipping with AI features that either do not work well, do not improve the user experience, or actively make the product slower and less reliable than the deterministic version would have been.

The right way to think about it is to start with what AI is genuinely good at right now, and then check whether your build is actually one of those situations.

AI is good at handling unstructured input. Text, conversations, documents, images, audio, anything that has historically required a human to interpret before the rest of the system can act on it. If your build needs to read incoming customer emails and categorize them, summarize a long document into a structured brief, extract data from invoices that come in dozens of different formats, or parse free-form notes into a clean record, AI is genuinely the right tool. The deterministic alternatives require either rigid forms that frustrate users or expensive human effort. AI removes both.

AI is good at search and retrieval over large internal knowledge bases. If your team needs to find the right answer across hundreds of documents, past projects, support tickets, or product manuals, a properly built retrieval system with a model on top of it produces meaningfully better results than traditional search. This is especially true for internal tools where the corpus is private and conventional search tools never had the data to learn from.

AI is good at first-draft generation. Proposals, emails, summaries, reports, anything where the team would normally spend twenty minutes starting from a blank page can be turned into a thirty-second review-and-edit task. The model does the cold start. The human applies the judgment. The combination is significantly faster than either alone.

AI is good at conversational interfaces over structured data. If your team is currently navigating a complex dashboard to answer a question that could be expressed in a sentence, putting a conversational layer on top of the data is often a real productivity win. The user asks, the system retrieves, the answer comes back grounded in the actual numbers rather than in the model’s guess.

Where AI is being oversold is in the places it does not yet do better than the deterministic alternative. Predicting outcomes from clean structured data, where traditional statistical methods are usually more accurate and far easier to reason about. Automating decisions that have legal, financial, or compliance consequences, where the lack of explainability creates more risk than the automation saves time. Replacing a workflow that already works well with one that runs slower, costs more per execution, and introduces failure modes that did not previously exist. Powering an interface where the user actually wanted a button to click, not a conversation to have. Each of these is a place where AI has been sold into custom builds and made the product worse rather than better.

The discipline we apply in our own work is to ask, for every place AI is being considered, three questions. Does this actually require AI, or would a simpler deterministic approach work and be more reliable. If AI is the right tool, can we constrain it enough to be trustworthy, with the right guardrails, fallbacks, and human review for the cases that matter. And is the output going to be measurably better than what the team would have produced without it, or are we adding cost and complexity for a marginal gain.

When the answer to all three is yes, AI earns its place in the build. When any of them is no, we leave it out, even if it would have made the pitch sound more modern. The custom software that wins over time is the software that solves the problem reliably, not the software that has the most fashionable architecture diagram. AI is part of that toolkit now, and it is genuinely transformative in the places it fits. The skill is in knowing where it fits and where it does not, and that judgment is one of the most valuable things a serious build partner brings to the work.

---

The last system we built solved the problem at the time but cannot keep up with the business now. How do I avoid that the next time?

The honest answer is that this failure mode is not always preventable, and any partner who promises otherwise is selling you a story. Businesses change in ways nobody could have predicted at the start, and software built against the operation of three years ago will eventually become software that does not fit the operation today. That is not a failure of the original build. It is the natural lifecycle of business software.

That said, most of the cases where a system becomes obsolete faster than it should have are preventable. The shortened lifespan usually comes from decisions made at the start of the build, and there are a small number of patterns that account for most of the failures.

The first is building to the current process rather than to the underlying intent. Custom software that hardcodes today’s specific workflow, today’s specific data structure, and today’s specific business rules will break the moment any of those change. Software that is designed around the underlying intent of the work, with the specifics implemented as configuration rather than as fixed logic, can absorb a surprising amount of change without needing to be rebuilt. The difference between the two is mostly invisible at launch. It becomes the difference between a system that lasts eighteen months and one that lasts five years.

The second is failing to think through where the business is heading. The discovery work at the start of a build should include serious conversation about the next two to three years. New product lines, new customer segments, new geographies, new operating models. The build does not have to solve for all of those upfront, but it has to be designed in a way that does not actively prevent them. Most systems that fail to keep up were built without that future-state conversation ever happening, and the architectural decisions that closed off future flexibility were made before anyone noticed.

The third is choosing the wrong architecture for the stage of the business. Over-engineering at the start, building a system designed to handle ten times the current volume and complexity, wastes money and slows the team down with abstractions they do not need. Under-engineering produces software that hits its limits within months. The right answer is to build for the actual current operation with explicit decisions about where the seams are, so the system can grow at the points where growth is likely and stay simple at the points where it is not. That requires a partner who can read the business and make those judgments, not just a developer who builds whatever is asked.

The fourth is treating the build as a project rather than as a system that will need to evolve. The most expensive systems we audit are the ones that were shipped, signed off, and then left to age in place. Nobody refactored as the business changed. Nobody extended the integrations as new tools came into the stack. Nobody owned the question of whether the system was still serving the operation. Three years later, the team is working around it and the cost of the rebuild is significantly larger than ongoing investment would have been.

The way we approach this is to architect the build with the change in mind from the start, to have the future-state conversation as part of discovery rather than as an afterthought, and to stay engaged with clients past the initial launch so the system continues to evolve as the business does. Some clients want a finite engagement and a clean handoff, and we can do that, with documentation thorough enough that another team can pick up the work. Most clients, once they see what the system can do, want us continuing to develop it. That ongoing partnership is what turns a custom build from a project that eventually becomes obsolete into infrastructure that scales with the business.

The next system does not have to outlive your business. It has to outlive the next few rounds of change, and be designed in a way that can be extended rather than replaced when bigger changes come. That requires the right architectural decisions at the start, the right partner engaged in those decisions, and the right ongoing relationship to keep the system aligned with the business over time. Get those three things right, and the system you build now should still be earning its place for years longer than the one it replaces.

---

Our Approach

Most custom software work follows the same pattern. The client describes what they want. The developer builds it. The system ships. The relationship ends. Somewhere in the months that follow, the team either adopts the software and gets some value from it, or they do not, and the project quietly becomes another expensive lesson about why custom builds are risky.

We do not work this way, and the reason matters.

The core issue with the standard model is that the client is usually not in the best position to describe what should be built. This is not a criticism of the client. It is a structural reality. Leadership can see the symptoms and feels the pain, but rarely has the time to sit with the team, walk through the actual workflow, surface the gaps, and translate any of that into a software specification. The people doing the work understand the friction intimately, but have normalized the workarounds and often cannot articulate what would actually solve the problem. The developer comes in with the technical depth to build, but no real exposure to the business or the team beyond a few scoping conversations. None of these three parties, on their own, has the full picture. And the brief that gets handed to the build reflects that gap.

The result is software built against a description that was incomplete, a workflow that was assumed rather than observed, and an understanding of the team that was thin. The technical execution can be flawless, and the system can still fail to fit the operation, because the diagnosis was wrong before any code was written.

Our work starts upstream of that. The first thing we do is sit with the people who will use the software. Not the people who described the problem to us. The actual operators, the actual managers, the actual day-to-day team. We walk through the work as it really happens. We ask the questions that surface the exceptions, the manual workarounds, the informal handoffs, and the moments where information is lost or duplicated. We watch where the team loses time and where they double-check things. We listen for the words they use to describe what they wish they could do. By the time we have a clear picture, the specification of what to build has usually shifted from what the client originally described, and it is almost always closer to what the business actually needs.

This is the work most agencies skip, and it is the work that decides whether the eventual build will be adopted or abandoned. Software designed against a real diagnosis of real work, by people who took the time to understand the operation, is software the team recognizes as built for them rather than imposed on them. Adoption follows from that recognition. It cannot be bolted on afterward through training and change management. It has to be built into the foundation of the engagement, and the foundation is the discovery work.

The other thing we do differently is that we treat the relationship as ongoing rather than as a project with a finish line. Real businesses change. The system that fit perfectly at launch will need to evolve as the business expands, adds product lines, enters new markets, or shifts how it operates. The custom builds that thrive over time are the ones with a partner who continues to develop them as the business grows. We stay engaged after launch. We refine. We extend. We add capabilities as the business identifies them. The system becomes infrastructure that scales with the operation, not a project that gradually drifts out of date.

The reason we work this way is that this is what care actually looks like in this category. Anyone can ship software against a brief. Very few partners are willing to do the harder work of figuring out what should actually be built, involving the team in the design, owning the adoption, and staying engaged for the years that follow. That work is more expensive for us to deliver than the standard model, but it is the work that produces systems your business genuinely benefits from, and it is the work we are committed to doing on every engagement.

When clients ask why our process is different, this is the answer. We do this because we have seen too many businesses pay for custom software they ended up not using, and we refuse to be part of producing that outcome. Software your team adopts and your business grows from is the only definition of success that matters to us, and our process is designed end to end to produce that result.

If you have been burned before by a custom build that did not land, or if you are about to commission your first one and want to do it right, the conversation we want to have with you is not about what we will build. It is about what is actually going on in the business, what the team is really struggling with, and what the right shape of the solution would be. That is where the work starts, and it is what turns custom software from a risk into one of the best investments a business can make.