Connect the work behind the screen.
Release what people can use.

The workflow matters more than the feature list.

A software idea often arrives as a list of screens: a dashboard, customer portal, schedule, reports, and mobile view. Those ideas may be useful, but they do not explain the operation. Before deciding what to build, we follow one real order, estimate, case, appointment, production job, or service request from beginning to end. We look at where the record starts, who changes it, and which decisions depend on it.

Then we walk through the inconvenient version of the job. Perhaps a customer changes an approved order, a price needs an override, or a payment arrives in parts. The important question is not how clean the demonstration looks. It is whether the system can preserve the right record and show the next responsible person what changed.

You do not need to prepare a technical specification before calling. Bring the spreadsheet, paper form, older application, shared inbox, and one representative example. CCD can turn that evidence into a clear account of roles, rules, information, and finished actions. The answer may be a custom system, a small connection, a configured product, or no new software at all.

The screen is only one part of the job.

The City of Detroit's published business-licensing path is a useful public example of a process that crosses organizational boundaries. Depending on the business, an applicant may have to assemble documents, address zoning, obtain permits, complete inspections, pay fees, and use an external licensing system. Progress depends on more than submitting one form. Different steps have different owners, prerequisites, evidence, and definitions of complete.

This is not a CCD project, and it is not an argument that Detroit's licensing process should be replaced. It also does not mean every Detroit business needs custom software. The practical point is simple: when your operation touches an outside portal, your internal system should not pretend it controls that external decision. It may need to record the external reference, current status, responsible employee, required document, and next follow-up while leaving the official approval in the system that owns it.

That boundary prevents a common design mistake. A new dashboard can display an internal status such as submitted, but only the outside authority can determine whether a permit or license is approved. The same distinction applies when a company works with payment processors, shipping carriers, customer procurement portals, insurers, or other third parties. Good software tells staff what is known, where it came from, and what they can do next without creating a second, unofficial version of the external record.

Look for the cost of the mismatch.

Custom software should earn the responsibility it creates.

Existing software is usually the sensible answer when the work is common and a mature product handles it honestly. Email, accounting, payroll, ordinary scheduling, and many standard customer-management needs already have supported options. Rebuilding a category from scratch adds development, security, maintenance, documentation, and support responsibilities without automatically making the business more effective.

A connection may solve the important mismatch while established products remain in place. A focused intake tool can validate information and send it to the back-office system. A reporting view can combine approved data without becoming the source of truth. A customer portal can expose selected status and documents while staff continue working in an existing application. Integration still depends on the other product's API, permissions, limits, and stability.

A custom system makes more sense when the distinctive workflow is important enough to own, disconnected products cause meaningful repeated work, or available tools cannot represent the necessary rules and permissions. Even then, the first release should complete a useful job without pretending to include every future idea. Discovery should provide enough evidence to choose among buying, configuring, connecting, and building.

The same record looks different to the people responsible for it.

A customer, field employee, office coordinator, manager, and accounting user may interact with the same job while needing different information and authority. Showing everyone the same dashboard is not simplicity. It can expose sensitive information, bury the next task, and make accidental changes easier. We define what each role can see, create, edit, approve, export, and remove.

The interface follows those responsibilities. A field user may need large controls, a short task sequence, camera access, and reliable behavior when connectivity is poor. Office staff may need search, correction tools, bulk actions, and a complete history. A manager may need exceptions and approvals rather than every routine detail. A customer should see only the information intended for that relationship.

Permissions also need administration. Someone must be able to add a user, change a role, remove access, and review who performed an important action. Authentication alone does not answer those questions. The scope identifies the access model, sensitive data, audit needs, and account-recovery responsibilities appropriate to the specific application.

What does custom software cost in Detroit?

Connected systems need clear authority over each record.

When two systems both contain a customer, product, price, or job, the project needs to identify which one owns each important fact. Copying changes in both directions without clear rules can multiply conflicts. We decide which record is authoritative, how the two systems identify the same item, and what staff see when a transfer fails. A person also needs a safe way to correct the problem without creating another duplicate.

Historical data deserves its own conversation. Older records may be incomplete or duplicated, and attachments may live somewhere other than the main database. A clean sample export does not prove the whole history can move safely. We inspect representative records, agree on what should be retained, test the conversion, and compare meaningful counts or totals before the final cutover.

Ownership should cover more than a download button. The agreement needs plain terms for business data and source code, along with the accounts, credentials, documentation, and third-party services needed to operate the system. It should also explain the handoff if another qualified team maintains it later. External platforms keep their own licensing terms, but access to the company's operational records should not depend on an unexplained vendor account.

A correct build still needs people, testing, and a cutover plan.

Testing should use real roles and representative work. A manager approving a clean sample is not enough if field staff, coordinators, customers, and accounting users encounter different steps. Testers need to know whether they are in a demonstration, training, or production environment and whether the information they enter will remain. Useful feedback names the task, expected result, actual result, device, and record involved.

The cutover plan defines when the new system becomes authoritative. Some applications can launch to everyone on one date. Others should begin with one department, customer group, or complete workflow. If old and new processes overlap, staff need a clear rule for where the official record lives. Otherwise a careful project can create two versions of the truth during its most vulnerable period.

After launch, separate defects from new requests. A feature that does not behave as approved is different from a working feature that now needs another option. Monitoring, backups, security updates, user administration, support channels, and future development responsibilities should be defined for the application rather than hidden behind the word maintenance.

Ask questions that still matter after the demonstration.

Not every digital problem needs a full operating system.

Answers for the first serious planning conversation.