Questions about commissioning custom software
When is custom development justified?
When a valuable task cannot be supported reasonably by existing tools, configuration, or a focused extension. We compare options using the same workflow and difficult case. The need for controlled decisions, record relationships, or an unusual handoff can be more significant than the number of screens requested.
Does every spreadsheet need to become an application?
No. A workbook can remain a suitable tool. Conflicting copies, unclear permissions, difficult history, or repeated coordination problems are reasons to investigate. The first result might be a better workbook or a smaller supporting tool rather than replacement.
Can you continue software another team built?
An assessment can establish the source, deployed version, records, dependencies, and access available. We compare the running behavior with the materials supplied before recommending repair or rebuilding. A folder of code is not proof that it represents the current application.
What belongs in the first release?
A complete useful task and the operating essentials it needs. That includes relevant permissions, exceptions, support visibility, and a way to verify the result. Optional reports and additional workflows can be deferred explicitly without leaving the first users unable to finish their work.
Is a prototype a working application?
Only to the extent actually implemented and verified. A prototype can test navigation and wording while simulating approval, records, or connections. Its review should say what it demonstrates and which technical responsibilities still need development.
How do you handle customer and employee access?
We define the relationship between the person, the record, and the permitted action. Acceptance includes refused access as well as successful work. Files, direct links, search, and exports need review alongside visible navigation. A sign-in mechanism does not replace application authorization.
Can you add single sign-on?
We can assess a supported connection for the actual identity provider, application, account plan, and authorized access. Invitations, role mapping, recovery, existing users, and departures need consideration. A protocol name alone does not establish compatibility or immediate revocation across every system.
Can the application connect to our existing tools?
That depends on their supported interfaces, provider terms, account capabilities, and permissions. We define which system owns each record and what happens if a transfer fails. A visible pending state and a targeted recovery action may be required alongside the connection itself.
What happens to existing data?
The scope identifies which records, relationships, files, and history move. We trial a controlled sample and reconcile the result with business owners. An import success message or matching row count does not establish that all relationships and meanings were preserved.
Can field work continue without a connection?
Where required, offline behavior is designed per task. Reading downloaded information, drafting notes, and confirming a shared action have different requirements. Local storage, pending work, conflicts, device limits, and recovery need explicit tests and operating guidance.
Who owns and maintains the finished system?
Source, hosting, provider accounts, data access, business rules, and support responsibilities are agreed in the engagement. Handover should make the next authorized maintainer's work possible. Continuous monitoring or urgent response is not automatically included in a completed build.
How are price and timing established?
They follow the reviewed scope, dependencies, available materials, and acceptance requirements. Uncertain integration or migration work may need an initial investigation. The proposal should identify assumptions and exclusions so the business can compare the actual commitment.