A small studio, deliberately
Working from Colombo with clients across several time zones. Remote-first, working across GMT+5:30 and overlapping EU/US hours.
Avenloop exists because of a pattern we kept seeing from the inside: software that demos beautifully, ships late, and becomes expensive to change within a year. Usually nobody was careless. The scope had simply never been written down, the architecture was decided under deadline pressure, and performance was something to look at after launch.
So we work in the opposite order. Scope and success criteria are agreed in writing before implementation. The risky parts get prototyped first, while there is still time to change course. Performance and accessibility targets are set at the start and enforced in the build pipeline, because a target nobody checks is a preference.
We stay small on purpose. The people who scope your project write the code, which removes the translation layer where most requirements quietly get lost. It also means we turn down work that we are not the right team for, and we would rather say that in the first conversation than the fifth sprint.
- Working since
- 2019
- Based in
- Colombo, Sri Lanka
- Engagement
- Fixed-scope sprints
- Code ownership
- Yours
The rules we actually apply
These are not values on a wall. Each one changes a decision we make during delivery, and you are welcome to hold us to them.
Write the scope down
Ambiguity is not resolved by starting sooner. Discovery produces a document you could hand to another studio, which is the point: it means the scope is real.
Boring architecture
We choose the least novel technology that solves the problem. Novelty is a cost paid by whoever maintains this after us, and often that is your team.
Measure, then optimise
Performance work follows real user data, not intuition. We instrument first so we can show what a change actually did rather than assert it.
Accessible by default
Keyboard navigation, contrast and screen-reader behaviour are part of the definition of done, not a remediation project after a complaint.
Hand over properly
Documentation, tests and a walkthrough with your engineers. Our aim is that you could stop working with us without it being disruptive.
Say the unwelcome thing
If a deadline is unrealistic or a feature is a bad idea, you will hear it early. That is more useful than agreement that unravels later.
Work with us, or just ask
A short call costs you nothing and usually clarifies whether there is a project here at all. If there is not, we will tell you.