Custom software development process

A maintainable sequence: walk the job, freeze v1, lock permissions and interfaces, then build, test and train. Starting with screens is how projects reopen forever.

Discovery follows documents, not slogans

Interviews that only hear "we need digital" produce a slogan. Collect how a purchase order is opened, who signs, and how a bad line is reversed. Photos of paper and Excel beat a survey.

Freeze what v1 will not do

A common failure is stuffing a three-year roadmap into the first release. V1 should go live alone: org, permissions, masters and one main flow. Dashboards and forecasts can wait.

Permission matrix and interface list

Who sees price, who may edit stock, who may export customers — decide before development. ERP or warehouse links need codes, posting time and retry rules in writing. Complex floor work is a parallel WMS track, not a hidden extra screen.

Build, integrate, accept, train

Milestones, not a fog of "almost done". Integration uses the counterparty test books, not a laptop full of private sample data. Acceptance follows the memo. Go-live needs accounts, backups and a defect window.

Frequently asked questions

Can we skip the prototype?

Small tools can. Systems with approvals, many roles or external APIs that skip prototype leave the argument for test week.

Can requirements change during the build?

Yes, through a change note that moves scope or calendar. Verbal extras with no schedule change usually damage both quality and the relationship.

What do you hand over?

Source, API notes, permission matrix, deploy notes and role-based training. A running URL alone is not handover.

Describe where documents live today and which systems must connect. We will map that onto this process at /en/software/.

See the service Contact