The first contract LeafyCode ever signed wasn't glamorous. The National Youth Services Council needed two things at once: a public site for the National Youth Award division, and an internal system to run it. The brief was tight, the budget was Sri Lankan, and the timeline was eight weeks.
We made one decision before we wrote a line of code. We'd build it on Ruby on Rails.
In 2014 that was not the easy local choice. Most agencies in Colombo were still selling PHP because that's what the client recognised and that's what kept change orders short. Rails was the international product-team standard at the time. We picked it because we wanted, on day one, to be a studio whose work could sit next to anyone else's anywhere in the world without looking provincial. Eight weeks later, the system was live.
Twelve years on, we are still here. We have never taken outside investment. And almost every operating rule we live by traces back to the way we approached that first project.
The decision that fixed every later decision
The conventional move for a small Sri Lankan dev shop in 2014 was to position as cheap offshore capacity. The pitch wrote itself: same talent, half the cost, time-zone overlap with Europe. It worked. It still works for shops that want to run that play.
We didn't take it. Not because the model was wrong — it wasn't, and isn't — but because we had watched the second-order effects up close. A team selling itself on cost has to keep getting cheaper. Every renewal becomes a margin negotiation. The talent you can attract caps out at the wage you can pay. The kind of work you can take on caps out at the bandwidth of whoever's writing the spec for you.
We made a different choice. We'd price for the engineering, not the headcount. We'd take work where the buyer wanted a team, not a vendor. We'd ship the work ourselves rather than pad headcount around a junior pool.
This is also why we have never accepted outside investment. We've had several offers over the years. We've turned all of them down. The studio exists to build real things — to put the name of Sri Lanka on innovations that ship — and that goal does not survive a board whose first question is next quarter's margin.
The cautionary tale we keep in mind is Boeing. As the line goes — McDonnell Douglas bought Boeing with Boeing's own money. The engineer-led board got replaced by accountants. Costs were cut where they should not have been cut. A company that used to be a byword for safety became one people are nervous to fly. We do not want to be that company, at any scale, ever. Engineers should be the ones deciding what to build and how to build it. Letting that decision drift to a balance sheet is how a software studio turns into a body shop without noticing.
What "useful" means when nothing fashionable lasts
Twelve years is long enough to watch the fashion cycle in software run twice.
We started on Ruby. We've shipped serious work on JavaScript and TypeScript, on NodeJS, NestJS, and NextJS, on TanStack, on React and React Native, on Tauri, on Flutter, on Go. We've stored data in MongoDB and PostgreSQL, in Firebase, Hasura, and Supabase. We've deployed on AWS, on Google Cloud, on Azure, and on Kubernetes. We use WordPress when WordPress is genuinely the right answer. Today, we work on almost anything the problem calls for.
The breadth isn't a list we keep around to impress procurement. It's a side effect of the one rule we've kept: pick the tool the problem actually needs, not the one the team is most comfortable with.
The Sri Lanka Model United Nations website is the cleanest example. We built the first version on Meteor and React, which was the right call for a reactive single-page site at the time. Years later, when SLMUN needed an easier way for their team to update content between sessions, we rebuilt the site on WordPress. Same client, opposite stack, because the second version was solving a different problem. The ERP we built behind SLMUN was its own system — managing Asia's largest student-run UN simulation, with 1,000 to 1,250 delegates aged 13 to 20 from across the world — and it lived on its own stack on its own release cadence.
The pattern repeats across the work we've shipped. Whiteberry Interiors was a hybrid WordPress + React build that started, literally, in a Sri Lankan WordPress meetup conversation about whether you could marry the two cleanly. We thought yes. We built one. House of Henley was on WordPress because the client was a working architect who needed to edit pages himself; he came back to us for a second project, which is the only kind of repeat business we count. Vishwarekha was a WooCommerce build on WordPress because that's the right tool when the brief is a Sri Lankan online marketplace with a content team in the back. Jaya Lanka Tours was Meteor + Node + React because a reactive single-load travel site, in that era, was the right answer.
None of those technology picks are universally correct. Each was correct for its project. That, after twelve years, is what useful has come to mean to us.
What we're doing right now
The twelve years are context. They're not the point. The point is what the studio is choosing to build today — because that's the only honest signal of where it's headed next.
Three pieces of work define LeafyCode in 2026.
The in-house product is BisBig, a modular ERP and workspace currently in closed beta. Three pieces are usable today. BisBig Recruitment, the HR module on the BisBig Platform, lets a company post jobs, take applications, score them with AI, and hire — free up to five active roles, with the limits visible on the billing page itself rather than in fine print. BisBig Jobs, the public board the Recruitment module publishes to, is built on the line every application gets an answer — aimed directly at the resume black hole that defines too much of modern hiring everywhere. Ridura, the sister mobile app for Sri Lankan drivers, ships vehicle QR codes, fuel economy logging, a crowd-sourced fuel-availability map, and the daily fuel-day check tied to local plate-rationing rules.
Hiring is the first slice. The longer arc is wider. BisBig is built to absorb the working surface of a company end to end — recruitment, project management, sales and point of sale, inventory, the audit trail that ties them together, the customer ledger, the supplier ledger, the role-based permissions that decide who can see what. Each piece is a module on the same workspace. You turn on what you need; the rest stays out of the way. The aim is to give a company one honest workspace instead of seven different cloud subscriptions that don't speak to each other and don't agree on whose number is the right one.
The Project Management module is publicly marked coming soon, but it isn't a placeholder. We and a handful of partner companies have been running on it internally for a while now — it's how our own engineering team plans sprints, runs kanban, and tracks heads-down time on a desktop timer. We'll lift it into the public catalogue when it's ready to be trusted by people who didn't help build it. The Sales and Inventory modules are honest coming soon tiles inside the product itself — visible on the sign-up wizard with "Notify me" buttons. Not promised in a pitch deck. Not buried in a roadmap PDF.
BisBig is built as an international product. We're a Sri Lankan studio, and the platform ships with Sri Lankan defaults, but the architecture is multi-locale by design — every currency, timezone, and date-format choice is a per-organisation setting, not a fork of the codebase. The default is a starting position, not the audience. Those problems — hiring, project work, sales, inventory, the audit trail under all of it — look the same in Galle, in Singapore, and in Lisbon.
The most involved client engagement is an AR smart-glasses project. It uses AI, alongside several other technologies we haven't seen put together in quite this combination before. We can't say more publicly yet. When the client is ready, we'll say more.
The R&D piece is The Lab — internal, multi-year, working toward a product that combines AI and IoT, with devices our team is building from scratch. We are not ready to talk about it. When we are, you'll know.
Alongside the product work, the community piece. SLDevTalks — formerly Leafy Katha — is the podcast we make for Sri Lankan developers, by Sri Lankan developers. The country has remarkable engineering talent. We want to find that talent, build a real community around it, and let it challenge the world together.
Twelve years, one steady direction
We don't chase platform shifts. We pick projects whose problem we understand, and we use whichever combination of stack, hardware, and engineering practice fits that problem. We refuse the investment route because we want to keep being the people who decide what we build. We work on big systems and small ones, in Sri Lanka and abroad, for ministries and founders and small studios alike.
If you're considering building something — a system, a product, a hardware-meets-software piece that other studios don't want to touch — and you want a team that talks like this and ships like this, we'd love to hear about it: hello@leafycode.com.
Pubudu Kodikara is the founder of LeafyCode International (Pvt) Ltd. Working on something like this? Tell us about it: hello@leafycode.com.
