Naming looks like a small detail in most codebases, but it quietly shapes how a system holds together. I realise that sounds grand for what most teams treat as a bike shedding exercise. "Should it be buyer_id or buyer_uuid?" "Should this field be called owner
There's a question every technology company should be asking itself right now: if AI can write code, what exactly are you selling? For years, the software industry operated on a simple premise — the hard part was building the product. Writing the logic, wiring up the integrations, shipping a
Last week, we had our annual company offsite in Sedona, Arizona. While we spent plenty of time hiking among the red rocks, riding a hot air balloon, and visiting the Grand Canyon, we also had an important mission while we were there: to make everyone in the company a builder.
For a long time, there has been a clear gap between engineering and the business. Product defines → Engineering delivers Context gets translated into tickets → tickets into code This model made sense when execution was expensive. Writing software took time, coordination, and careful planning. The separation between thinking and building was,
Product teams receive a constant stream of feature requests. Dashboards, exports, notifications, integrations. Each one makes sense in isolation. A customer asks for something specific, the team sees a clear gap, and the natural instinct is to prioritise it. Over time, these requests accumulate. Roadmaps begin to fill with features
The hardest part of building software has changed. It used to be the building itself — the months of development, the cost of getting it wrong, the weight of every commitment. When shipping a feature took a quarter, less than ideal prioritisation was easy to hide. Long cycles gave you cover
For most of my career as a software engineer, I’ve tried to follow the practices that make engineering sustainable: writing tests, keeping changes small, reviewing carefully, documenting intent. Recently, while reflecting on how my way of writing code has changed with the introduction of AI coding tools, I realised
The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up. - Akin’s Laws of Spacecraft Design #15 (Shea’s Law) Full stack engineers are supposed to be generalists, but at some point in the last few years "
Nowadays, everywhere you look, people are talking about AI agents. They’re on social media, in the news, in product demos, startup pitches, and everyday conversations. Agents are creating their own social media accounts, pushing code to repositories, managing inboxes, and even starting drama online. Some describe them as personal
Data modelling is often treated as a specialist discipline. It requires SQL proficiency, familiarity with a transformation framework, and an understanding of conventions that are rarely fully documented. As engineering organisations grow, this lack of shared context can limit who is able to contribute to the data layer. Connecting an
It is often said that human beings are distrustful by nature. We distrust people we do not know, the media, advertisements, and anything else that has not earned our trust. But if we had to highlight something that makes us most distrustful, it would be technological advances in artificial intelligence
The industry consensus is shifting fast: the days of developers spending 80% of their time manually typing syntax are numbered. Even Ryan Dahl, the creator of Node.js, recently said “the era of humans writing code is over”. At Opply, we aren’t just watching this happen - we’ve
We don't have software engineers at Opply. Not because we don't write software — we write plenty — but because the title describes the wrong thing. It puts the emphasis on the output rather than the outcome. Job titles shape expectations. Expectations shape behaviour. Call someone a software
Recently, I have been reflecting on how the idea of prototyping is often interpreted in software. Too frequently, it is treated as an MVP: an intentionally imperfect product that resembles the real thing, but is never meant to truly be it. Something built quickly, used briefly, and ultimately thrown away.
Imagine you have deployed an AI agent in your team that approves payments, deals with invoices and makes financial decisions. One day, it makes a call that results in a significant monetary loss. Who takes responsibility? Is it the developer who built the agent? The team that deployed it? The
Prompt engineering has become part of daily work for many people with the rise of modern LLMs like ChatGPT, Claude, Gemini, DeepSeek and others. In simple terms, it is the practice of structuring and phrasing instructions for AI systems so that they can perform tasks more accurately. Whether you’re
In fast-moving startups, engineering happens under pressure: ambitious roadmaps, evolving priorities, limited resources, and a constant need to deliver value quickly. Under these conditions, one mindset consistently outperforms all others: Pragmatism. At Opply, pragmatic engineering is not about cutting corners or lowering standards. It’s about focusing relentlessly on outcomes,
At Opply, we’ve always had great engineers. Talented, fast, committed. But when I joined, something was missing. Not skill, not dedication, but ownership. We were brilliant executors. Hand us a ticket, and we would deliver. Hand us a bug, and we would fix it. Features got built, tickets got
Opply is entering an important new phase, one where our technology, our pace of innovation, and our team's work deserve to be seen. This blog is the first step in asserting our readiness for a public-facing tech presence and sharing the story behind what we are building. Why