Company · How we work
How we work together.
We don't run one process for everything. A small project doesn't need the same process as a multi-phase public contract - the amount of management is matched to the work.
As much process as the project actually needs.
What this means for you
- one contact for the whole project
- clear milestones and visible project status
- no unnecessary process on small projects
- documentation and formal acceptance where they are required
Three delivery models
Small project
Brief → build → test → deliver. A project lead and one or two people delivering, with no layers in between.
Product or system
Discovery → UX → architecture → development → testing → launch. Every milestone has a working build on staging.
Complex public project
Requirements → project plan → teams → development → integrations → QA → documentation → acceptance → SLA.
Production and event
Brief → preparation → delivery → post-production or on-site execution, with a crew aligned to the digital side of the project.
How an engagement starts
You do not need a specification. Most projects start from a description of a problem, an existing system, or a date by which something has to work. From that we define the scope - and if there is not enough to estimate on, we say so rather than quoting a number that will not hold.
- a conversation about the problem and what a good outcome is
- a review of the current state, where a system already exists
- a scope separating the first phase from what comes later
- a quote that states clearly what is not included
- a bounded audit, where there is too little to quote on
What happens during delivery
Most projects fail not on technology but on silence: the client hears nothing for three weeks, and when they see the result it is not what they pictured. So we show the work before it is finished, not only at handover.
- one accountable person for the whole project
- regular reporting, including when there is nothing new
- a working interim result rather than a progress description
- an agreed process for changing scope
- decisions written down so they are not re-litigated
What happens after handover
Handover is not the end. A system with nobody maintaining it breaks by itself within a year or two: a certificate expires, an external service changes, a vulnerability appears in a library. So what happens afterwards is agreed before delivery starts.
- documentation and access held in the client's name
- training for the people who will use the system
- an agreed maintenance scope and response times
- monitoring and alerting on failure
- the option for someone else to take maintenance over
Process
Kick-off
A record of goals, constraints and responsible people.
Analysis
A map of the current process and a requirements list.
Specification
Functional specification, phases and an investment estimate.
Prototype
A clickable prototype of the key screens.
Development
A working build on staging at the end of every phase.
Integrations
Interface specs and working data transfer.
Testing
Test scenarios and a defect resolution report.
Handover
Production environment, documentation and training.
Measurement
Analytics and a usage report after the first month.
Maintenance
SLA, monitoring and an agreed volume of enhancements.
Engagement models
Full Project
we deliver the entire project
Project Module
we deliver a defined lot
Dedicated Team
we extend your team
Consulting
we help with planning
Development partner
long-term product development
Production partner
long-term production support
Related solutions
Sounds like your project?
Send us the project description, your existing system, the tender documents or the event date.