Custom Software Development

What Discovery Needs From Your Side

Discovery is the phase most dependent on the customer and the one most often under-resourced on the customer side. A build plan is only as good as the material it is built from, and the gap between how a process is described in a meeting and how it runs on a Tuesday afternoon is where estimates break.

The other thing discovery needs is an answer on authority: who arbitrates when two departments describe the same process differently. Without that, contradictory requirements get resolved by whoever spoke most recently, the resolution changes when the other department sees the increment, and the increment gets built twice.

• Real exports from the systems in scope, including the malformed rows and the historical records nobody wants to look at. A cleaned sample hides exactly the cases the software has to handle.
• Sandbox or non-production credentials for every API in scope, requested early. Vendor approval for API access is frequently the long pole, and it is out of everyone's hands once the request is filed.
• An hour or two each with the people who do the work today, not only the people who can describe it in summary. The workarounds are never in the summary.
• The side spreadsheets and personal tools staff built to fill gaps in the current systems. They are the requirements document nobody wrote down.
• The reports and exports that must keep working after the change, named individually, along with who receives each one and in what format.

What an Integration Inventory Covers

Before an integration can be scoped honestly, both ends have to be inventoried, because the design is constrained by the least capable API in the chain rather than by the architecture you would prefer. A system that exposes no bulk read, or that returns 200 records per request behind a rate limit, sets the refresh interval regardless of what the requirement asks for. The inventory is what turns "the two systems should talk" into a shape with a known cost and a known failure behavior.

• What the integration is actually for: a one-way copy, a two-way sync, or an event on one side that triggers work on the other. Those three have different failure modes, and only the second one requires conflict resolution.
• The endpoints and the operations they expose, including whether bulk or paged reads exist or records have to be fetched one at a time.
• The auth model: a static API key, OAuth 2.0 client credentials, or a user-scoped token, and how long a credential lives before renewal. A user-scoped token means the integration stops working when that user leaves the company.
• Rate limits, both documented and observed, and what the API returns when you cross them. An HTTP 429 with a Retry-After header is recoverable with backoff; a silent throttle or a dropped connection is not.
• Whether change notification exists at all: webhooks, a modified-since filter, or nothing. Absent the first two, every run is a full scan, and cost scales with the size of the dataset rather than with what changed.
• How the far side represents deletion: a hard delete, a status flag, or nothing a polling client can observe. If deletions are invisible through the API, no sync built on polling stays correct without a periodic full compare.
• Sandbox availability, and whether the sandbox holds data shaped like production. A sandbox seeded with ten tidy records tests the happy path and nothing else.

Migration, Reconciliation, and the Cutover Decision

Replacing an existing system is usually two projects: the software, and moving the data. The second is where schedules slip, because the source data is older than anyone still working there and encodes rules that were never written down. Field mapping is the easy half. Reconciliation, proving that what landed matches what left, is the half that takes the time.

Records that fail validation are the decision point, and the decision belongs to the customer rather than the developer. Every migration surfaces rows the new rules reject: contacts with no valid email, orders referencing customers that no longer exist, dates stored as text in three formats. Each class needs an answer, either loosening the rule, correcting the data, or building a quarantine path for bad rows that someone reviews after go-live. Leaving these open is how a migration turns into an open-ended one.

• A trial load into a non-production copy, run more than once, with record counts and financial totals compared against the source rather than spot-checked by eye.
• A written mapping from source field to target field, including the fields deliberately left behind and the reason each one was dropped.
• A cutover shape chosen in advance: a parallel run with both systems live, or a freeze window and a single load. Parallel running costs double entry for a period; a freeze costs downtime. There is no third option that costs neither.
• A rollback position: what happens if the load finishes and the reconciliation does not balance, and who is authorized to call it.
• A decision on history: how far back to migrate, and whether the old system stays available read-only for everything older than that line.

Access Rules, Deletion, and Audit

Access rules are the requirement most often deferred in discovery and the most expensive to add afterward, because they are not a feature in one place. They cut across every screen, every report, and every API endpoint, so retrofitting them means auditing every query that returns data rather than adding a permissions page. Deciding them early costs a meeting; deciding them late costs a pass over the whole codebase.

These questions are also the ones only the customer can answer, because they are policy rather than engineering. The same word means different things in different organizations, and the software has to implement one of them.

• Who can see what, expressed as individual actions rather than a list of job titles. Titles get reorganized; the actions stay stable, and roles are then assembled from actions.
• What "delete" means here: whether a removed record is truly deleted or only marked inactive, who can still see the inactive ones, and whether anything downstream still references them.
• Whether the system has to record who changed what and when, and how long that history is retained. An audit trail added later cannot reconstruct the period before it existed.
• Approval steps, if any exist, and what happens to work in flight when the approver is on leave. A queue with no fallback path stops the process rather than the record.
• What happens at offboarding: whether a departed user's open records transfer automatically, to whom, and whether their historical activity stays attributed to them.

When a Custom Build Is Not the Answer

Some requests that arrive framed as custom software are better served without it, and that assessment is worth making before the estimate rather than after. If the requirement is a single point-to-point sync between two systems with a stable field mapping and no business logic on either side, a hosted integration platform can carry it without adding code that then has to be maintained. That is a narrower case than it sounds. As soon as the mapping carries rules, spans more than two systems, or has to reconcile records that both sides can change, the logic exists somewhere regardless, and a vendor's configuration screen is a worse place to keep it than a repository with a history and tests.

Two other cases argue against building. The first is scale: a workbook with a single owner, a few dozen rows a month, and nobody downstream depending on it is not a system of record and does not need replacing. The second is timing. If the underlying process is about to change because of a reorganization, an acquisition, or a regulatory change already scheduled, building now encodes a process with a known expiry date, and the more useful work is the integration or reporting layer that survives the change.