Question 1

Which services sit under Build?

Accepted Answer

Two services sit under this discipline: custom software and mobile apps, and technology and infrastructure advisory. One writes the product, the other builds the infrastructure it runs on. In most engagements they share a schedule, because when the architecture decision and the hosting decision are taken separately, the cost of that gap only surfaces after the first release.

Question 2

Why build custom software when off-the-shelf exists?

Accepted Answer

Off-the-shelf gets ruled out first, every time. Scoping writes down the problem, the constraints and the success criteria, and if a product on the market meets all three we do not propose custom work. Custom software earns its place when the process fits no existing product, or when the cost of the dependency outgrows the system itself. Those two thresholds decide it.

Question 3

Who owns the source code?

Accepted Answer

The source code stays with the client in full. Code, infrastructure access and the architecture documentation are all part of delivery. Nothing technical is left in the way of continuing with another team after handover. Ownership is a way of working rather than a contract clause: the code is readable, the decisions are written down, and infrastructure is set up in the client's own accounts.

Question 4

How long does an MVP take?

Accepted Answer

The average MVP takes 8 weeks. The span depends on scope, and scoping sets the scope: which success criteria make the first release is decided there. When the schedule grows, the fix is narrowing the first release rather than adding people. A first release that cannot be narrowed usually means the success criteria were not written sharply enough.

Question 5

When is the technology chosen?

Accepted Answer

Technology is chosen last. The problem, the constraints and the success criteria come first, and the tool is picked against those three. Working in the reverse order bends the problem to fit the tool, and the price of that shows up after the first release. Once the choice is made, its rationale and the alternatives ruled out are written down so the decision stays open to review.

Question 6

How are architecture decisions recorded?

Accepted Answer

Architecture decisions are recorded through ADR discipline. Every significant choice is written with its rationale, the alternatives ruled out and the consequence, so the decision history is readable by the time code starts. A year later the question of why something works this way has a written answer, and the team inheriting the system does not have to rerun the same debate.

Question 7

How do we see progress?

Accepted Answer

Progress shows through weekly demos. A working piece is shown every week and each demo is a sign-off point where scope changes get discussed too. There is no surprise delivery, because every step has been seen before the last one. Demos also reveal early where scope is expanding, moving the schedule conversation to the middle of the project instead of the end.

Question 8

What happens after go-live?

Accepted Answer

Thirty days of stabilisation follow go-live. Observability is wired from day one, so problems surface in measurement rather than through users; live behaviour is watched and corrections are made during that window. At the end of it the system is handed to the internal team. The handover package includes the working documentation, the monitoring dashboards and a list of known limits.

Question 9

Build or Transform — which one fits us?

Accepted Answer

Transform fits when a system already covers the need, Build when none does. Transform connects and speeds up what exists; Build writes what is missing. When existing software keeps producing exceptions and every new requirement creates manual work, the answer usually sits on the Build side. Where the call is unclear, process mapping settles it in a single inexpensive step.

Question 10

Do integration-heavy projects count as Build?

Accepted Answer

Integration-heavy projects fall under Build. At MKComputer most of the work was the data pipeline and the server architecture: stock, price and supplier data for more than 200,000 products is pulled from the supplier's XML feed and refreshed every five minutes. The interface sits on top of that pipeline, and the visible part was the smaller half of the job.

Question 11

Where does the work start?

Accepted Answer

Every Build engagement starts with scoping. The problem, the constraints and the success criteria are written on a single page, and the timeline and the proposal come out of it. If that page cannot be written, the work is not defined yet and it is too early for code. On undefined projects the cost accrues not while writing code but while the scope shifts later.

Build

No prescription without diagnosis.

Scoping

Architecture

Build

Go-live + handover

The expertise at the core.

Custom software & mobile apps

Technology & infrastructure advisory

Fast entry doors.

MVP Build

Frequently asked questions