Services
Four disciplines. An enquiry can touch two of them, and there is no need to know which before you write. Find the sentence below that sounds like your week.
Somebody does the work by hand, or in a spreadsheet that three people have their own copy of. You know what should happen; what you do not have is a way to tell a developer.
This is a development engagement, and it starts by deciding whether the thing belongs in a browser or on a phone — a decision that changes the cost more than any other.
Web and mobile app development
Releases are frightening. The same bug comes back. Someone finds a problem in production that nobody saw in testing, and the fix breaks something else.
This is a testing engagement — but not always. If everything breaks on every release, the problem is upstream in how the software is built, and more testing will only tell you so more often. We will say which one it is.
Quality assurance and testing
The feature exists and nobody finds it. New staff need training to do something that should be self-evident. Users keep a spreadsheet alongside the system that was supposed to replace it.
This is a design engagement. The first job is separating problems of structure — where things live and in what order — from problems of surface, because they cost very different amounts to fix.
UX and UI design
It runs, and the person who built it has gone. Nobody has logged into the hosting account for a year. You are not sure who owns the domain, and a dependency warning email arrives that nobody understands.
This is a support engagement, and taking over software someone else built has a defined first step that is not code: finding out what you actually have access to.
Technical support
In practice
Anything with more than one kind of user needs the structure decided before it is built. Doing the design after the build is how software ends up with a feature nobody can find.
Tests written alongside the build cost a fraction of tests retro-fitted afterwards, and they are the only reason a change in month six does not break something from month one.
A regression set is what makes ongoing support affordable. Without one, every small change needs the whole system re-checked by hand.
A usability review of live software is its own piece of work, and it separates the fixes that are cheap from the ones that need a build, so the cheap ones can go first.
Say so in the enquiry rather than choosing the nearest. Describing the problem in your own words is more useful than picking the right category, and a job that is not ours is better identified in the first exchange than in month two.
Describe what happens in your week and let us work out the category. Getting it wrong in the enquiry costs nothing.