How we would work, written down before you commit
This is the software development process we would propose, from the first conversation to the handover. It is written down so you can question it before you commit, not after.
Principles
Four principles behind every step
One change first
Where the work allows, we would propose one change before any wider program: one interface, one report or one working piece. That way you judge real work before the scope grows.
Plain writing anyone can check
Scope, gaps and decisions would be written in plain words. The people who own the problem should be able to read them, not only engineers.
You own what we build
Everything we build is yours: the code, the repository, the domain and the accounts it runs on. The aim is that it keeps running whether or not we stay involved.
Saying no when it isn't a fit
If the work needs skills we do not have, or another kind of firm would serve you better, we would say so before quoting, not after.
The steps
Five steps, from enquiry to handover
A starting point for discussion rather than a fixed method. Each service page sets out its own version for that kind of work.
- 01
The first conversation
It would cover what you need, who depends on it, and what is already fixed: a platform, say, or a team that must stay involved. If another kind of firm would serve you better, we would say so here.
You would holdA plain answer on whether we are the right fit
- 02
Read what exists
We would look at what runs today, or at the notes and decisions behind an idea. This reading can be scoped as its own piece of work, separate from anything built afterwards.
You would holdA written record of what exists, yours whatever you decide next
- 03
Write the gap and agree the first change
The output should be a short description of what is missing and what closing it involves, in words the owners of the problem can read. Then we would agree one change to make first.
You would holdA written description of the gap, and one agreed first change
- 04
Build it in the open
You would see the work as it takes shape: running software, a staging site, or a test build on your own phones. The old way of working would stay in place until you choose to rely on the new one.
You would holdA working first change you have tried yourself
- 05
Hand it back documented
Anything built should come with documentation, access records and a handover to your team. You should be able to end the arrangement without the system breaking.
You would holdDocumentation, access and everything built, in accounts you control
What stays yours
Yours, whatever you decide next
- The code written for you
- The repository, with its history of changes
- The domain, registered in your name
- The hosting, cloud and app store accounts
- The documentation and access records
- The written record from the first read
Boundaries
What we would not do
Publish prices or timelines
Cost and timing depend on scope, and scope would be agreed after the first read. Any figure would be set out in writing for the specific work, not printed on a web page.
Promise what we cannot stand behind
Nothing on this site promises response times, availability or results. Where guaranteed cover is a hard requirement, a provider whose whole model is a staffed help desk is the better answer.
Learn at your expense
If the work needs skills we do not have, we would say so rather than take it on. A specialist in that field would serve you better.
Hand decisions to software
Where a step needs a person's judgment every time, it should stay with a person. Automation would prepare the decision, never make it.
Questions
Questions about the process
Is this software development process the same for every project?
No. It is a starting point for discussion, not a fixed method. Each service page sets out its own version of the steps, and we would adapt them to your situation.
Can the first read be a separate piece of work?
Yes. Reading what exists can be scoped on its own, separate from anything built afterwards. You keep the written record it produces, whatever you decide next.
Do I have to commit to the whole project at the start?
Not necessarily. The process is built around changing one thing first, so both sides can judge real work before the scope grows. Whether to go further would be a separate decision.
Can you work alongside our own team?
Yes. Several services are written to work with the people who already run the system, such as your SAP team, an existing integrator or your internal recruiters. If your team already does the work well, we would say an outside firm adds little.
Can Traittek stay involved after the handover?
That can be discussed, for example as a maintenance arrangement. Either way, you should be able to end it without the system breaking.
Tell us what you'd like built.
Bring the idea, or the system that needs to change.