// SOFTWARE ENGINEERING
Software engineering
Engineers who deliver your features and leave your codebase in better condition.
Our engineers join your team and take on real work from the first sprint. They also bring the practices that make a codebase easier to maintain: smaller pull requests, reviews that share knowledge, and tests that find defects before your users do. Over the following months your team's code improves because the developers have adopted those practices, rather than because a policy was imposed.
What your team gains
An engineer who has worked across several codebases notices things that a team gradually stops seeing. These include the module nobody wants to change, pull requests so large that they wait days for review, and defects that return in a slightly different form after each fix.
Our engineers deliver the work they were brought in for and, in the course of doing so, reduce those problems. They pair with your developers on difficult changes, write a test before fixing a defect and explain their reasoning, so that the practice is understood and adopted rather than simply followed.
- Features delivered by engineers who work independently
- Code reviews that identify design problems early, not only style issues
- Automated tests where they provide clear value, and fewer where they do not
- Faster growth for junior developers, who learn by working alongside experienced engineers
How our engineers improve your practices
Our engineers do not arrive with a fixed set of rules. In the first few weeks they learn your codebase, your conventions and the reasons behind them. Some decisions that look unusual from the outside turn out to be sound, and others are worth revisiting.
They then introduce small, visible improvements. Typical examples are a shared review checklist, a pre-commit hook that runs the linter so formatting no longer needs discussion, or a large refactor broken into steps that can each be merged separately. Each change is small enough for your team to see its benefit and continue the practice.
We follow a principle we call Simplicity by Design: the simplest approach that solves the problem. In practice this means fewer elaborate abstractions and more code that a new team member can read and understand within days of joining. Our engineers will make the case for this in your design discussions, while respecting the decisions your team makes.
Working within your stack and processes
Our engineers work in your repositories, with your tools and within your process. If your team runs two-week sprints, so do they, and they adopt your deployment and review practices as they find them. They are based in Centurion and work with clients across South Africa, so they keep your hours and join your stand-ups in person or online.
You communicate with them directly. If something is not working, you can raise it with them or with us, and we will resolve it. There is no layer of account managers in between.
We grade our engineers by what they can do rather than by the number of years they have worked. An engineer who has spent three years building and running systems in production may be more valuable than one who has spent ten years maintaining a single application. When we propose people, we explain their level and what it means for your team, so that your choice is based on capability.
// FAQ
Frequently asked questions
Will they work our hours and use our tools?
Yes. They work in your repositories, issue tracker and chat, follow your branching and review rules, and keep South African working hours. If you would like them on site on certain days, we can arrange that.
Which languages and frameworks do your engineers know?
That depends on the individual. Tell us what you use and we will only propose engineers who have built production systems with it. We do not place someone on your team to learn your stack at your expense.
What happens if the person is not a good fit?
Please tell us early. We will speak to you and to them, and if the situation does not improve we will propose someone else. A poor fit is costly for everyone, so we treat it as a priority.
How will our own developers respond to someone coming in to improve things?
In our experience, well, provided it is handled properly. Our engineers establish trust by doing good work first and suggesting changes second. Most teams welcome help with problems they are already aware of.
// RELATED SERVICES
Quality and testing
Testers who find problems early and establish a process that continues to find them.
Cloud and DevOps
Routine, predictable releases and infrastructure your team understands.
How it works
A clear, straightforward process from the first conversation to a specialist working within your team.