Software development with consistent attention and room to adjust
Software must be able to grow with the way you work. With Developer as a Service, we work continuously on new functions, improvements and technical quality.
We make it clear in advance what has priority and deliver in stages, so that usage and feedback can influence the next choice.
Ongoing software development with DaaS
With Developer as a Service, we work on your software on an ongoing basis. You engage an agreed level of development capacity. Together, we decide which items take priority and what should happen next.
DaaS does not provide unlimited software or a fixed number of new features each month. Progress depends on the agreed capacity, the complexity of the work, dependencies and the choices we make together. We work at three levels: the direction on the roadmap, the prioritised worklist for the coming period and a concrete delivery moment for a defined component.
For a new application, we start with the task that needs to be supported. For existing software, we start with an assessment of code, architecture, data, dependencies, users, access and major risks. We do not promise a full takeover before that status has been investigated.
That assessment also determines how quickly something visible can be delivered. With a well-documented application, a first improvement can be implemented faster than with a system whose structure must first be figured out.
A development cycle in practice
- 1.Choosing priority. The customer determines together with us which component receives attention first.
- 2.Establishing acceptance criteria. It is fixed in advance what the result must comply with.
- 3.Building and testing. The component is developed and checked before it goes to the user.
- 4.Reviewing with the user. The person working with it indicates whether it supports the task.
- 5.Controlled delivery. The component goes live within the agreed environment.
- 6.Determining the follow-up. The next priority is chosen based on what has been learned.
The frequency of this cycle differs per collaboration. A short cycle of a few weeks fits one organisation better, while a longer cycle with more preparation time per step fits another. This is agreed upon per situation, not fixed as a standard.
The role of the customer
An external development team does not automatically replace internal ownership. Someone within the organisation must be able to choose priorities, organise access, answer questions and assess whether an application actually supports the task.
What 'ready' means for a small component is also recorded: the agreed usage works, relevant rights have been checked, found errors have been discussed and the user knows how to work with it.
Without a point of contact on the customer side, the risk arises that priorities change without a clear reason, or that feedback only reaches the development team late. Both slow down work more than a short weekly alignment would cost.
A completed worklist
- 1.New function: automatically create a file for a new request. Reason: requests are now tracked separately. Acceptance criterion: every incoming request gets a file with the correct basic data.
- 2.Improvement for users: clearer overview of open tasks. Reason: employees sometimes miss a pending step. Acceptance criterion: every user sees their own open tasks on one screen.
- 3.Technical maintenance: replace outdated link. Reason: the current link occasionally gives an error message. Acceptance criterion: data is transferred without error messages during an agreed test period.
These three types of work are deliberately placed side by side. Only building new functions without attention to maintenance leads to more errors in the long run and a greater chance of delay in future work.
Starting small, fully working
A first version preferably supports one complete small task, instead of multiple functions that work halfway.
A common mistake is starting several large functions at the same time, resulting in nothing being fully finished on time. A smaller, working first version provides usable feedback sooner than a halfway working whole.
Clear about capacity and scope
The proposal sets out the development capacity and any additional roles included in the engagement. It also explains the arrangements for design, project management, testing, documentation, maintenance and ongoing support.
Hosting, licences, AI usage and other external services require their own arrangements. Do not assume that every provision is automatically included in the development price.
The investment depends on the scope and agreed level of work. The proposal explains what is included and which external costs are charged separately.
Our general terms provide for a licence to use the software. Different ownership arrangements must be agreed in writing. The engagement should also specify the access, documentation and handover included.
These agreements are put on paper per collaboration, so they are not dependent on loose promises during a conversation.
When this working method is less suitable
If you need a fully defined project with a fixed price and a fixed delivery date for a one-off application, then DaaS is not the form that fits that. In that case, first discuss which form of collaboration is suitable.
More about the broader technology choices can be found on the page about technology. See also automation, AI applications and the Kitchen Studio case.