Samuel Mfinanga · Named engineer · 20+ years infrastructure
Shape the first conversation
Start with the decision in front of you.
Answer what you know; every question is optional. Your choices prepare an editable brief, not a price or a delivery promise. Only these fixed choices travel to Contact; do not enter private records here.
The broken workflow, in the words of the person who does it
Milestones written before the build
The interface, the data, and a path to production
Custom Software: what this includes
Custom Software: the work in scope.
01What you keepThe handoff names repository access, data export, documentation, and who operates the system. Ownership and licensing terms are agreed in writing.
02What we will not cloneIf NEXUS already does the job, we will not rebuild that product for one company.
Custom Software: the practical distinction
What changes when this work is done here.
A feature list from a demo.
The break, described by the person who does the work.
A custom copy of a product they already sell.
If NEXUS already does it, we will not rebuild it.
The workflow
How software gets shipped
01The broken workflowIn the words of the person who does the work. Not a feature list from a demo.
02The first sliceThe smallest production-ready slice, with milestones written before the build.
03The buildThe interface, the data, and a path to production. The same kind of stack we run ourselves.
04The handoffYou can run it. We stay for the next slice if you want. We do not fork a NEXUS product into a one-off.
Start with the work that needs to change
Four software jobs. Different first moves.
A new workflow, an integration, a legacy replacement, and a troubled build need different evidence. Find the job you have before committing to a feature list.
01
Replace a manual workflow
Where does the work leave a system and re-enter through a spreadsheet, inbox, or person?
Bring to the conversation
Bring one real case, the people who perform and approve it, exceptions, current tools, and the time or errors it creates.
Ask to see in the scope
Ask for a workflow map, an agreed first usable slice, acceptance examples, and a named operating owner after release.
02
Connect systems and data
Which record is authoritative when two applications disagree or an integration fails?
Bring to the conversation
Identify source systems, data owners, interfaces, permissions, failure paths, and information that must not leave its boundary.
Ask to see in the scope
Ask for a data-flow diagram, reconciliation rules, error handling, audit needs, and a test using non-sensitive records.
03
Modernize a legacy application
What must keep working while an old system is replaced in stages?
Bring to the conversation
Bring current users, critical transactions, dependencies, export options, outages you can tolerate, and the owner of cutover decisions.
Ask to see in the scope
Ask for a phased replacement map, data migration checks, parallel-run or rollback criteria, and a defined retirement point.
04
Rescue or extend a build
Is the next useful step a new feature, a reliability fix, or an honest stop decision?
Bring to the conversation
Share access to the existing code and deployment path, known defects, usage evidence, security concerns, and current support terms.
Ask to see in the scope
Ask for a bounded technical assessment, prioritized options, a testable next milestone, and clear code, data, and access handoff.
The first useful software brief comes from the person doing the task today. Show where information enters, where a decision is made, and where the result must land.
01
The current path
Walk through one real case, including exceptions and handoffs. Count the time, re-entry, and errors before deciding which screen to build.
02
The first slice
Choose the smallest workflow that could be used in production, who would use it, and what success would look like after release.
03
Systems and data
List existing tools, records, permissions, integrations, and migration needs. Identify sensitive data before choosing the architecture or test environment.
04
Ownership after launch
Agree on code and data handoff, hosting, support, and the next decision point. A custom build should not become a hidden dependency on its builder.
What gets scoped
The written scope defines the first production slice, interfaces, integrations, data responsibilities, testing, deployment, handoff, and separately priced later work.
These sources help frame the questions. They are not a LUCA certification or a promise that every control is included in a service quote.
Before you choose
Questions worth settling before you switch.
Should we build custom software or configure a product we already have?
First test whether an existing tool can support the workflow, permissions, and data boundary without forcing harmful workarounds. A custom build needs a clear business reason and an owner for its ongoing operation. A product license and a custom service are different scope decisions.
Can you replace our old system without stopping the business?
A staged plan can reduce cutover risk, but zero interruption cannot be promised. Inventory the transactions and integrations that must continue, choose a limited first slice, test data migration, and agree on rollback or parallel-run criteria before switching traffic.
What will the first phase deliver?
The first phase should name the users, one bounded workflow, acceptance examples, dependencies, security requirements, and who decides whether it is ready for use. Discovery, implementation, migration, support, and later features should be separated in the written scope.
How are security and sensitive data handled?
Classify the data and access paths before choosing an architecture or test environment. Define authentication, authorization, logging, dependency review, and test-data rules in scope. A custom build is not automatically compliant, secure, or suitable for regulated records.
Who owns the code and data after handoff?
Write down repository, infrastructure, credentials, data export, documentation, and operating access before work starts. Ownership and licensing terms belong in the human-approved agreement; the website alone does not transfer rights. The handoff should be tested, not inferred from a code archive.
Can AI be part of this application?
Only when it helps a defined task and the data, accuracy, review, and failure boundaries can be agreed. Start with a measurable use case and a human review path for consequential outputs. Do not assume an AI feature, model, or autonomous action is included in a software quote.
How we quote
Scope
Quoted per scope
For
Ops and engineering leads replacing fragmented tools with a workflow fitted to their business.
