Custom software development

Software built for work where a wrong result is costly, with the checks that show it is behaving correctly before anyone relies on it.

Write a brief Book a meeting

Parts of a build

Most projects involve several of the parts below. Which ones depend on what the software has to do and how much rests on it getting the answer right.

Working out the requirement: Sitting with the people who will use the software and writing down what it has to do and what it must never do.
The hard cases first: Finding the inputs and edge conditions that would cause real damage, and building so those are handled early.
A running version early: Getting a working piece in front of users quickly, so the design is corrected against how the software is actually used.
Testing against known answers: Checking the software on cases where the correct result is already known, so failures surface before the software goes live.
Fitting the systems you have: Connecting the software to the data and tools your team already uses.
Hosting: The software runs where you choose, on your own servers or in your own cloud account.
A handover that sticks: The engagement leaves your people ready to run the software and to extend it once the work ends.

Building for work where a wrong answer costs money

Most software is built to handle the common path well and the rare case eventually. That order causes little harm when a wrong result means a frustrated user and a bug report. It becomes the wrong order when a wrong result means a bad trade or a figure that reaches a board before anyone notices it is off. For work of that kind, the cases that almost never happen are often the ones worth building for first.

The approach that holds up begins from what the software must never get wrong, then builds outward from there. A working version goes in front of the people who will use it within weeks, because a specification agreed in a meeting tends to miss the conditions that only appear once the software is in real use. Each piece is checked against cases whose answers are already known. The behaviour is watched after the software is live, because software that passes every test can still meet an input nobody anticipated.

Amos has written software for more than twenty years, and the person who agrees with you what the software has to do is also the one who writes it.

How to start

The brief

Describe what the software has to do and which inputs or results carry the most risk if they are wrong. Say where its data sits now and which systems it has to work alongside.

Confidentiality

If the work touches sensitive systems, a non-disclosure agreement can be in place before anything is shared.

Who does the work

Amos Weiskopf studied computer science at the University of York and has been building software for more than twenty years.

Questions buyers ask

What is custom software development?

It is software built to do a specific job for one company. Here the focus is work where a wrong result is expensive, so the software is checked against known answers and built to handle the cases that carry the most risk ahead of the rest.

How much does custom software development cost?

That depends on what the software has to do and how many systems it has to work with. The price is set once the brief is in.

How soon is there something to use?

A working version is often in front of users within weeks, because putting a piece in early corrects the design against real use. The timetable for the rest is agreed in the brief.

Does the data stay under our control?

Yes. The software runs on your servers or in your cloud account, and nothing goes to an outside service without your agreement.

Will our own people be able to run it?

Yes, and the software is built with that in mind. Your team is left able to operate it and to extend it after the engagement ends.

How do you know the software is correct?

It is checked against cases where the correct answer is already known, before it goes live and again once it is in use.

Engagements by written brief.

Work begins from a documented problem statement, not a sales call.

Write a brief Or book a meeting