Software R&D Services
Web, mobile, IoT and API development, plus architecture and delivery, done by senior engineers under the same technical leadership that set the direction. AI-assisted speed, held to a professional standard.
Triggers
Sometimes the answer to a technical problem is a decision. Sometimes it is a decision and then the work to carry it out.
The standard
Fast is easy now. Trustworthy is the job.
AI tools write much of the first draft, and the team uses them fully. Every change still goes through human review, tests that check behaviour rather than repeat the code, and guardrails in the pipeline, so the speed never costs you correctness or understanding.
You get regular written reports: what shipped, what is at risk, and what changed in the plan, against the baseline agreed at the start. Problems are raised when they are found, not at the end of a sprint.
You talk directly to the engineers and the technical lead doing the work, not to an account manager. The work happens where you can see it, in your repositories, tickets and pipeline, and the decisions behind it are written down.
Integration and expansion
Situations that come up as a company adds customers, sites, devices or products, and the part of the work Kendoo takes ownership of in each.
We draw the line between product and customization: which integration interfaces the core supports, who owns each customer-specific piece, and how custom work is scheduled so it stops crowding out the roadmap.
We own the dependencies between firmware, cloud services and apps: versioned interfaces between them, compatibility rules, an end-to-end testing boundary, and one release sequence all three teams work to.
We turn per-site setup into repeatable configuration, define what each system records and passes on, and set the test and rollout steps for a new site, so a failure can be followed from one system to the next.
We map where the products overlap, decide the interfaces and data they will share, set the migration sequence, and agree which team owns what, so integration work does not stall existing commitments.
Capabilities
The technology is chosen from what you already run and who has to maintain it afterwards.
Optimising development technologies and workflows toward growth and scalability, so the engineering choices and the commercial ones are made against each other rather than in separate rooms.
Robust, efficient and maintainable architecture designed for the long run, including cloud and microservices transitions where those genuinely fit the problem.
Tailor-made, responsive web applications, across legacy and modern stacks: Java, .NET, PHP, Node.js, React, Angular and Vue. Existing systems as readily as new ones.
Native and cross-platform apps using iOS, Android, React Native, Kotlin, Flutter and Ionic, chosen against how the app will actually be maintained rather than by preference.
REST, gRPC and GraphQL APIs that connect your systems, applications and services, designed as contracts other teams can rely on rather than endpoints added one at a time.
IoT applications and controllers on Arduino, Raspberry Pi and similar platforms, including the part most projects underestimate: what happens when a device is offline.
Releases, infrastructure or cloud costs the problem? Cloud & DevOps
The argument
A great deal of consulting ends at the recommendation. The document is sound, everyone agrees, and then it meets a team with no capacity and a roadmap already committed. Six months later the same problem is raised again, usually with the same document attached.
The reverse fails too. Development capacity with no technical ownership produces exactly what was asked for, including when what was asked for was wrong, and the architecture drifts a little further with each delivery.
Keeping both in the same engagement is what makes either worth buying. The people making the architecture decisions are working next to the people implementing them, so the decision survives contact with the code and the code reflects the decision.
How it runs
The code, the incidents and the constraints before any proposal. Most of this work is on systems somebody else built, and that is a different discipline from starting clean.
What the engagement builds, what your team keeps, and how the two meet. Ambiguity at that seam is where delivery problems come from.
Working next to your engineers rather than in parallel to them, so the knowledge stays with you and the decisions stay grounded.
Documentation, review and coaching as part of the work. A system your team cannot maintain has not been delivered, whatever the status board says.
Where the volume of work genuinely calls for a large delivery organisation, that is said on the call. Scoping honestly is cheaper for everyone than discovering the limit halfway through.
No, and the difference matters. The engineers work under the same technical leadership that sets the direction, which is why the architecture decisions and the code that implements them stay consistent. Work is scoped to what can be owned properly rather than to whoever is on a bench.
Usually. Most of this work is on systems somebody else built, which is a different discipline from starting clean: reading the code, finding what the tests do not cover, and changing it without breaking the parts nobody remembers.
Preferably. Working next to your team leaves knowledge behind and keeps the decisions grounded in what your engineers will have to maintain. Handing over a finished system to a team that has never seen it is how a rewrite starts.
From what you already run and who has to maintain it, not from what is currently interesting. A stack your team cannot hire for or support is a liability regardless of its merits.
Results
Real engagements, shared anonymously. The situation, the decisions, and what changed.
Explore the resultsThirty minutes on what exists today and what has to be true when it is done.