Custom Software Development

Custom software fails most often not because of bad code but because it was built against an incomplete or inaccurate model of how the business actually works — the difference between the documented process and the process people actually follow day to day, with all its exceptions and workarounds. Before any development starts, I spend real time understanding the actual workflow: who does what, in what order, what happens in the common case, and just as importantly, what happens in the edge cases that occur often enough to matter but rarely enough that they get glossed over in a first conversation.

This modeling covers users and roles — who needs to see what, who needs to approve what, what happens when someone is out and a task needs to be reassigned — because permission and workflow logic that's bolted on after the fact tends to be fragile and full of gaps compared to logic that was designed in from the start around a real understanding of the organization's actual structure and how work actually flows through it.

It also covers data: what information the business already has, in what format, of what quality, and what new data the software will need to capture going forward. Migrating existing data is very often the most underestimated part of a custom software project — a spreadsheet with years of inconsistent manual entry rarely maps cleanly onto a proper structured database, and I scope that migration work explicitly and honestly rather than let a client discover partway through that their existing data needs significant cleanup before it can even be imported into the new system.

The output of this modeling phase is a written specification both sides can review and sign off on before a fixed price and timeline are committed to — not a legal document meant to create friction later, but a shared, specific reference that means the eventual software gets evaluated against what was actually agreed to, rather than against an evolving and increasingly vague memory of what someone thought they asked for months earlier.

Custom software has to be built for the business the client will be in two or three years, not just the business they are today, because rebuilding foundational architecture later is expensive in a way that's easy to underestimate at the outset. That means real thought given to data modeling up front — how entities relate to each other, what will need to change as the business adds new products, new locations, or new types of customers — rather than a schema that only comfortably fits the exact scope described in the first conversation.

Permission and access-control architecture deserves the same forward-looking treatment. A system built with only two roles — admin and everyone else — because that's all the business needs on day one will almost always need more granular roles later as the team grows, and retrofitting a proper permission system into software that was never designed for one is disproportionately expensive compared to building it in from the start, even if only two roles are actually configured and used at launch.

Integration points get the same scrutiny: what other systems does this software need to talk to now, and what's realistically likely to be added later — an accounting package, a marketing platform, a separate internal tool. I design the software's boundaries with reasonable extensibility in mind, using clean, documented internal APIs even where an external integration doesn't yet exist, because software that was built as a completely closed system is measurably harder and more expensive to connect to anything else once that need inevitably arrives.

None of this means over-engineering for hypothetical future requirements that may never materialize — that's its own expensive mistake, adding real complexity and cost today to serve a future that may not unfold as predicted. The actual skill is judgment: which extension points are cheap to build in now and likely to matter, and which are speculative enough to defer until there's real evidence they're actually needed, a judgment call I make explicitly and explain rather than apply silently based on instinct alone.

These architecture decisions are also where an inherited codebase most often shows its age. A system with no clear extension points, a flat permission model bolted onto years later, or a database schema that quietly assumes only one location or one product line, is usually not a sign of bad original engineering — it is a sign the business genuinely outgrew assumptions that were entirely reasonable at the time they were made, which is exactly the situation a modernization project is meant to address.

A custom software project that plans for one large launch six months or a year out is a project with a long stretch of time during which nobody outside the development team can see whether things are actually on track, and by the time that gap closes at launch, any misalignment between what was built and what was actually needed has already been fully built into the product. I structure custom software delivery in shorter, working increments instead — a genuinely usable slice of real functionality shipped every few weeks, not a demo of unconnected pieces, so the client is interacting with real, working software throughout the project rather than waiting for a single reveal at the very end.

This incremental approach also changes how requirements get handled when they inevitably shift. Business needs discovered six weeks into a year-long project are expensive to accommodate if the whole system was designed monolithically around the original requirements; they're much cheaper to accommodate when the software has been built and delivered in increments, because a change discovered early only affects the increments that haven't been built yet, not a mountain of already-completed work built on an assumption that's since changed.

Prioritization of which increment ships first follows a deliberate logic: the piece that delivers the most real business value soonest, and separately, the piece that's technically riskiest and most likely to reveal an architectural problem, both get pulled earlier rather than later. Building the easy, low-risk parts first because they're fast to demonstrate progress on is a common and understandable temptation that I actively resist, because it postpones the discovery of real problems to a point in the project where they're much more expensive and disruptive to fix.

A significant share of custom software work is modernizing an existing system rather than building something entirely new — an internal tool that's grown organically over years, accumulated technical debt, and become genuinely risky to change, where the business needs a path forward that doesn't mean discarding a system with years of accumulated business logic embedded in it, logic that isn't always documented anywhere except in the code itself. My first step is always a real technical audit of what exists: what's salvageable, where the actual risk concentrates, and what a realistic, staged modernization path looks like compared to a full rewrite.

Full rewrites of legacy systems carry a specific, well-documented risk that's worth naming directly: the business logic embedded in an old system, however messy the code itself might look, usually represents years of accumulated edge-case handling that nobody remembers the reasoning behind anymore, and a rewrite that doesn't carefully capture all of that logic quietly loses functionality that mattered, sometimes not surfacing as a real problem until months after the new system has already gone live and someone hits the specific case that got lost.

Where possible, I favor a strangler-pattern approach to modernization — building new functionality alongside the legacy system and gradually routing traffic and users to the new components as they're proven reliable, rather than a single high-risk cutover from an old system to a completely new one on a single launch day. This approach costs somewhat more in engineering overhead during the transition period, maintaining two systems in parallel for a while, but it dramatically reduces the risk of a catastrophic failure on launch day, because problems get discovered and fixed incrementally against a smaller, contained blast radius rather than all at once against the entire system in production.

Unlike a consumer product with a large user base to generate real-world usage data, internal business software often has a small number of known users performing well-understood tasks, which changes how testing should actually work. I test primarily against the real workflows the software was modeled around during the specification phase, walking through the actual end-to-end processes a real employee would follow rather than testing individual features in isolation, because bugs in custom software disproportionately live in the connections and handoffs between steps rather than within any single, well-defined screen.

Edge cases matter more in custom business software than in many consumer products, because the small number of internal users will hit those edge cases regularly as part of normal, everyday work — the customer with no email address on file, the order that gets partially refunded, the employee who needs to be reassigned mid-task — rather than encountering them as rare events. I build a specific test plan around the edge cases surfaced during the original workflow modeling exercise, treating them as first-class requirements rather than as an afterthought addressed only if time allows once the happy path is fully working.

User acceptance testing with the actual people who will use the software day to day is a required stage, not an optional nicety, because the people who understand the real workflow best are the ones best positioned to catch a subtle mismatch between what was built and what's actually needed — a mismatch that's often invisible to a developer testing against the specification alone, since the specification itself may have missed a nuance that only becomes obvious once a real user tries to do their actual job with the finished software.

Business software lives or dies on whether people trust the data it shows them, and that trust, once broken by a single visible discrepancy, is very hard to rebuild — a report that shows the wrong number even once teaches users to double-check everything the system tells them from that point forward, which quietly defeats much of the software's actual purpose. I build data integrity in as a first-class architectural concern: proper database constraints rather than relying purely on application-level validation that can be bypassed by a bug elsewhere, transactions that ensure related changes either all succeed or all roll back together, and audit logging on anything where knowing who changed what and when genuinely matters to the business.

Reporting and dashboards get particular scrutiny, because a dashboard is exactly where a subtle data or calculation error becomes most visible and most damaging to trust in the whole system — a number that's off by a small, easy-to-miss margin can go unnoticed for months until it eventually drives a real business decision, at which point the actual cost of that small original error becomes very real. I test calculation logic against known, manually-verified examples before any dashboard or report ships, rather than trusting an implementation to be correct just because it compiles and runs without producing an obvious error.

For software supporting financial or otherwise consequential decisions, I build in reconciliation checks — automated comparisons that flag when numbers that should always match each other across different parts of the system don't, surfacing a data integrity problem quickly rather than letting it silently compound and grow harder to trace back to its actual root cause the longer it goes unnoticed.

This is also why I resist the instinct to build the cheapest possible version of an integration just to get it working for a demo. An integration that technically succeeds under ideal conditions but has no retry logic, no logging, and no defined failure behavior is not really finished — it is a problem deferred to the first time conditions are not ideal, which for any integration running in production is a matter of when, not if.

Custom software is priced against a genuinely different calculation than a website, because the comparison isn't against a template — it's against the ongoing cost of whatever the business is doing today, whether that's a manual workaround, an ill-fitting off-the-shelf tool, or a growing pile of spreadsheets. I try to make that comparison explicit and honest during scoping: what is the current process actually costing in staff time, error rate, and missed opportunity, and does the projected cost of custom software pay that back within a timeframe the business actually cares about — a year, two years, whatever horizon is realistic for their planning.

Fixed-price quoting works well for custom software once the workflow modeling phase is complete and both sides have a written specification to price against, and I favor that approach over open-ended hourly billing for exactly the same reason I favor it for website work: it puts the incentive on scoping accurately and building efficiently rather than on running the clock. For genuinely exploratory projects, where even the client isn't yet certain what the software should ultimately do, I recommend a phased approach — a smaller, fixed-price first phase focused on the core, best-understood workflow, with later phases scoped and priced once real usage has clarified what actually needs to be built next.

The ongoing cost of custom software also deserves honest treatment upfront, because it doesn't stop at delivery the way a marketing site's does — hosting, monitoring, security patching, and periodic feature additions as the business evolves are all real, recurring costs that should be part of the initial conversation rather than a surprise discovered a year after launch. I give clients a realistic sense of that ongoing cost during scoping, not just the number to build the first version, because a business that only budgets for the initial build and not for keeping the software healthy afterward is setting itself up for an unpleasant surprise down the line.

The strangler pattern also gives the business a natural off-ramp if priorities change mid-modernization. Because the legacy system keeps running throughout, a paused or descoped modernization still leaves a working system in place, rather than leaving the business with neither a finished new system nor a functioning old one, which is the genuinely bad outcome a stalled full rewrite can produce.

Almost no custom software exists in isolation — it needs to pull customer data from a CRM, push transactions to accounting software, sync inventory with a supplier's system, or authenticate against an existing identity provider, and the quality and reliability of those integrations very often matters more to the eventual success of the project than any single piece of custom-built functionality. I map every required integration during the specification phase with the same rigor as the core workflow itself: what data flows in which direction, how often, what happens on failure, and what the acceptable latency is for each connection.

Third-party API quality varies enormously and is frequently outside anyone's direct control, so I build resilience into every integration rather than assuming the other system will always respond quickly and correctly. That means proper retry logic with backoff for transient failures, clear logging so a failed sync can actually be diagnosed rather than silently disappearing into an unmonitored void, and a defined, sensible fallback behavior for when an integration is down — does the software queue the action and retry later, does it alert a human, does it degrade gracefully to a reduced but still-functional mode — decided deliberately in advance rather than improvised under pressure the first time a real outage actually happens.

Where an integration touches a system the business considers critical — payments, inventory levels that affect what customers can actually order, anything with real financial consequences if it goes wrong — I build monitoring and alerting specifically around that integration's health from day one, not general-purpose application monitoring alone. Finding out an integration silently failed three days ago because a customer complained, rather than because an alert fired the moment it happened, is exactly the kind of gap that erodes confidence in custom software fastest, and it's also one of the most straightforward things to prevent with a modest amount of deliberate monitoring built in from the start.

Increments also give both sides a natural, low-stakes point to reassess priorities. If real usage of an early increment reveals that a feature originally planned for a later phase actually matters more than expected, or that something on the roadmap turns out to be far less important than assumed, that reprioritization can happen cheaply between increments rather than requiring a disruptive renegotiation partway through a monolithic, single-phase build.

Custom software has a specific documentation problem that off-the-shelf products don't: there's no vendor knowledge base, no public forum of other users who've hit the same issue, no support team to call when something's unclear — whatever documentation exists is whatever actually got written during the project, which makes it considerably more consequential than it might seem for a piece of internal tooling that only a handful of people will ever directly use. I write real, practical documentation as part of every custom software project: how the system is architected, what each major component does, and critically, why specific non-obvious decisions were made, not just what the code does but the reasoning a future maintainer would otherwise have to reconstruct from scratch.

This matters even when I expect to remain the ongoing maintainer, because good documentation makes every future change faster and safer regardless of who's making it — a well-documented system lets even the original developer move faster months later, rather than having to spend the first hour of every maintenance session re-deriving context that was never written down anywhere in the first place. And it matters considerably more when a client might eventually bring the software in-house or hand it to a different developer, because undocumented custom software with no departing knowledge transfer is close to a liability at that point rather than an asset — a system nobody can safely change without real risk of breaking something they don't fully understand.

For anything genuinely complex — an unusual business rule, a workaround for a specific limitation in a third-party system, a piece of logic that looks wrong at first glance but is actually correct for a non-obvious reason — I document the reasoning directly in the code as well as in separate written documentation, because comments explaining why something unusual was done tend to survive longer and get read more reliably than a separate document that's easy to lose track of, forget exists, or simply never open once the initial handover conversation is a distant memory.

I would rather have this conversation openly during the project than let a client discover the drift only when the final invoice looks bigger than the number they remembered agreeing to at the start, because that gap, however honestly earned, damages trust in a way that is disproportionate to the actual value delivered by the extra work.

For a focused internal tool — a single core workflow, a small number of user roles, one or two integrations — the specification phase typically takes two to three weeks: workflow modeling, data mapping, a written spec both sides review and approve, and early wireframes for the key screens. This phase moves at the pace of getting the details genuinely right rather than the pace of simply getting a proposal signed, because the accuracy of this phase is what makes the fixed-price quote that follows actually reliable rather than a rough guess dressed up as a firm number.

Development then runs in the incremental delivery pattern described earlier, typically in two- to three-week working increments, each one shipping real, usable functionality rather than an internal-only demo. For a project of this size, the first genuinely usable version — covering the core workflow end to end, even if secondary features are still pending — is usually ready somewhere between six and ten weeks in, with subsequent increments adding the remaining scope, refinements from real usage, and any secondary workflows that were deliberately deprioritized behind the core one.

Larger, more complex systems — multiple interconnected modules, several integrations, more elaborate permission structures — extend this proportionally, but the sequencing logic stays the same: specify thoroughly, build the highest-value and highest-risk pieces first, deliver in real working increments a client can actually use and give feedback on, and treat the specification document as a living reference that gets updated as genuine learning happens during the build, rather than a static document nobody revisits once the project is underway.

The clearest positive signal in a custom software project is that the client is actively using each incremental delivery in something close to real conditions, not just reviewing it on a screen share and nodding along — real usage surfaces the gaps between what was specified and what's actually needed far faster and more reliably than review-only feedback ever does, because people notice friction in their own actual workflow that they would never have thought to mention in the abstract during a planning conversation.

A clear warning signal, on the other hand, is scope quietly growing without a corresponding, explicit conversation about cost and timeline — a series of small "while we're at it, can you also..." additions that each feel individually minor but that collectively can double a project's real size without either side ever having a clear moment to acknowledge that shift. I flag scope changes explicitly the moment they come up, even small ones, not to be rigid about it but because an honest, ongoing conversation about tradeoffs is what keeps a project's budget and timeline meaningfully connected to what's actually being built, rather than drifting apart from each other unnoticed.

Another meaningful signal is whether questions about the underlying business logic are still surfacing well into development — genuinely new questions late in a project usually mean the original specification missed something real, which is a normal, expected part of complex work and worth surfacing honestly rather than a failure to be defensive about. What actually matters is how quickly those questions get resolved and incorporated, because a project that handles new information calmly and adjusts course tends to end well; a project where new information causes real disruption to the schedule every time it surfaces usually means the underlying architecture wasn't flexible enough for the actual complexity of the problem in the first place.

Internal business software often feels lower-risk than a public-facing product because it isn't exposed to the open internet in the same way, and that intuition is partly right but dangerously incomplete — internal tools frequently hold the business's most sensitive data (customer records, financials, operational details competitors would value) behind what is sometimes weaker access control than a comparable public product would ever ship with, precisely because the lower perceived risk leads teams to under-invest in the same discipline they'd insist on for anything customer-facing.

I apply the same core security discipline to internal software as to anything public: proper authentication rather than a shared password everyone on the team happens to know, role-based access control that actually restricts what each person can see and do rather than a system where everyone effectively has admin rights because it was simpler to set up that way, and encryption for sensitive data both at rest and in transit, even for a tool that will only ever be accessed from inside a company network.

Employee turnover is a specific risk internal software has to account for that a consumer product mostly doesn't: access needs to be revocable cleanly and immediately when someone leaves the business, and I build access management with that reality in mind from the start rather than relying on someone remembering to manually disable an account weeks after a departure. A former employee retaining working access to internal business software, even accidentally through an oversight rather than malicious intent, is a real and completely avoidable risk that proper access architecture designed in from the beginning prevents at essentially no ongoing cost.