Our Team
A Small Team,
Deliberately
KaizenSpark Tech runs as a compact engineering group. Everyone here writes, reviews, or ships something. This page describes the roles we build around and how we work together.
We were incorporated in November 2024 and we have stayed small on purpose. A team this size means the engineer who scoped your project is the one who builds it, and the person who answers your question has read the code. We would rather grow slowly against real work than hire ahead of it.
Named profiles go up here as people agree to be published. Until then, the roles below are the honest version: what each seat covers, and who you would actually be working with. If you want to meet the team before committing to anything, start a conversation.
Company Culture
How A Week Actually Runs
Work is organised in short cycles with a demo at the end of each one. Nothing is called done because it was written; it is done when someone outside the pair that built it has used it and the tests pass. That rhythm is the whole culture, and it is why our estimates get more accurate the longer an engagement runs.
We are remote-friendly and asynchronous by default, which means decisions get written down instead of living in someone's memory. Disagreement is expected and is settled with a prototype or a measurement rather than seniority.
Leadership
Two seats carry the decisions: what the company takes on, and how a build is sequenced once it is agreed.
Founder & Director
Role currently held — name published soon
Company direction, client scoping, and the final call on what we take on and what we turn down.
Engineering Lead
Role currently held — name published soon
Platform architecture and delivery. Owns technical review, estimates, and how a build is sequenced.
Team Members
The delivery roles. People here cover more than one of these on most projects, which is what working in a small team looks like.
Full-Stack Engineer
Role currently held — name published soon
Application and API development across the enterprise software and SaaS work.
Cloud & Infrastructure Engineer
Role currently held — name published soon
Deployment pipelines, environments, cost sizing, and the operational side of what we ship.
Data & Analytics Engineer
Role currently held — name published soon
Pipelines, reporting, and the models behind our AI-assisted automation work.
Product Designer
Role currently held — name published soon
Interface design, prototypes, and the usability testing that happens before a build starts.
Specialist work outside these roles — security review, IoT firmware, video production — is brought in per project and named in the statement of work before it starts.
Values
Six working rules. They are operational rather than aspirational: each one changes what we do on a Tuesday.
Improve in small increments
Kaizen means change made deliberately and often. We would rather ship a narrow system this quarter and improve it every month than hand over one large release nobody has used.
Say what we measured
Claims come with a number and a method, or they do not go in the report. If we cannot measure a change, we say that too rather than round it up into a result.
Write it down
Architecture decisions, handover notes, and runbooks are part of delivery. The test is whether an engineer who was not on the project can pick it up without a meeting.
Review everything
Code goes through review regardless of who wrote it. Review is how standards stay consistent across a small team and how people here learn fastest.
Turn down the wrong work
We will tell you when software is not the answer, or when a cheaper process change gets you the same outcome. Losing a project in scoping costs less than delivering the wrong one.
Own it after launch
The months after release are where systems either compound or decay. We plan for that window rather than treating handover as the end of the engagement.
Innovation
We Experiment On Ourselves First
New tools, model providers, and architectural patterns go into our own systems before they go near a client project. Operon One and SkillTank are the sandbox: when an approach fails there, it costs us a sprint instead of costing you a release.
Engineers here get time to take an idea to a working prototype and present it. Most are rejected. The ones that survive become part of how we build, and we can tell you why we chose them.
Careers
Join Through The Work
We hire slowly and mostly from people we have already worked with. The main route in is SkillTank, our internship programme: trainees join a supervised track inside our own codebases, with code review and pairing as the teaching method rather than lectures. It is deliberately not a shadowing exercise — you write code that gets reviewed and merged.
There is no standing vacancy list. If one of the roles on this page describes what you do, or if you want a place on the next SkillTank intake, write to us with something you have built and what you would change about it now.