I’m Sadeepa, a software engineer at Lunova. I work from Sri Lanka, on UK hours, on Drivio, a SaaS platform for driving school and instructors. I joined in August 2026 and my part of it is the mobile app.
Three months in, the most useful things I’ve learned aren’t about code, who need to :joy:. They’re about learning a world I’d never lived in and writing things down so nobody has to wait for me.
Key takeaways
- Learn the client’s world before the code. A qualified driving instructor and a trainee are different legal statuses, and the software has to know it.
- Written context beats quick questions. On a remote team, every bug report should stand on its own.
- Write the time zone next to every time. A missing time zone was behind a real bug I found.
- Ask “is it the app or the data?” first. It sends each question to the right person the first time.
- Test like a user who isn’t you. A different place and different phone settings find different bugs.
Learning the client’s domain: ADIs, trainees and DBS checks
One of the first features I worked on the mobile app was the Badge and DBS page in an instructor’s account settings. It has two tabs. On the Badge tab, instructors choose their badge type, ADI or PDI, enter their badge number and expiry date, and upload a photo of the badge. The DBS check tab does the same for their criminal record check: certificate number, expiry date and a copy of the certificate. Once a document has been reviewed, the page marks it as verified.
I’d never heard of an ADI or a PDI before this project, so I had to learn why the page exists. GOV.UK’s step-by-step guide to becoming a driving instructor explains that you must become an approved driving instructor (ADI) if you want to charge people for lessons, which means passing three qualifying tests. After passing ADI part 2, you can apply for a six-month trainee licence to get experience teaching. People still in training are often called potential driving instructors, or PDIs.
Anyone applying also needs a new Disclosure and Barring Service (DBS) check, and qualified instructors renew their registration and get a new DBS check every four years. Between them, those two rules are the whole reason for a Badge and DBS page.
That changed how I read the feature. To someone outside the industry, the badge type looks like a dropdown. To an instructor it is their legal status, a trainee on a licence or a fully qualified ADI, and an app that gets it wrong is quietly misdescribing someone’s right to teach. Words like these end up as values in a data model, so I now read the client’s world before I read the codebase.
Working UK hours from Sri Lanka: 1pm to 10pm
My working day runs from 1pm to 10pm in Sri Lanka. During British Summer Time that’s 8:30am to 5:30pm in London. Since the clocks went back on 25 October, it’s 7:30am to 4:30pm.
Sri Lanka doesn’t change its clocks, so every October the UK day moves an hour away from mine. Rather than ask remote engineers to change their hours, Ashif Abbas, our managing director, starts at 7:30am UK time, so the team still overlaps for the whole of my day.
It’s a small thing, but it sets the tone. Making the time zones work is a shared job, not something the people furthest away absorb on their own. That shared understanding is what makes the habits below worth keeping.
Working hours apart means someone is often offline when a question comes up. The habit that helped most was writing everything down, so an answer never depends on who happens to be awake:
- Every bug report stands on its own. Steps, expected result, actual result, a screenshot or recording, and the device. Mozilla’s bug writing guidelines call steps to reproduce “the most important part of any bug report”, and I’ve found that to be true.
- Every time carries its zone. “09:00 UK” or “13:30 Colombo”, never just “9am”.
- Every day ends with a short note. What I finished, what is blocked, and what I need from whom.
If working like this suits you, we’d like to hear from you.
Time zones: the bug I found by being in a different one
Rule 2 sounds pedantic until it isn’t. While testing the lesson diary on my phone, a lesson booked for 09:00 to 11:00 sat in the 13:30 to 15:30 slot. The lesson was booked in London time, my phone was set to Sri Lanka time, and 4.5 hours is exactly the gap between them.
Our automated checks hadn’t caught it because they all ran on London time, so both sides agreed by accident. Being the one person on a different clock meant I could reproduce the bug simply by existing. It has since been fixed.
The general lesson is well documented. The W3C’s guide to working with time and time zones says a calendar or meeting schedule needs “the time zone (and not merely the local time offset)”, because a future event’s wall time depends on rules such as summer time. Zones have names, like Europe/London and Asia/Colombo, and the IANA Time Zone Database keeps the history of each one.
App or data? Working on one side of the system
I work on the app. The server side is built by other members on the team, and that changes how you debug. Before I raise an issue I answer one question: is this the app or the data?
I note what the app asked for and what came back, and put both in the report. If the data is already wrong, it’s a server question. If the data is right and the screen is wrong, it’s mine.
It helps to treat what comes back as a contract. Ian Robinson’s article on consumer-driven contracts describes how a consumer’s reasonable expectations of a provider become exactly that once the provider accepts them. I write my expectations down, so when one breaks we can see which side moved.
Design work is engineering work too
Some of my most useful learning came from design work. I learned to treat colour as a system rather than a list of hex codes: each colour has a name, and a change to it reaches every screen. The Design Tokens Format Module defines a token as “information associated with a human readable name”.
Every text and background pairing has to pass WCAG’s minimum contrast of 4.5:1 for normal text, and checking that automatically is cheaper than finding a failure by eye. I also learned to judge a screen on a real phone, next to the real screens around it, rather than in a mock-up.
What I’d tell anyone joining a remote team
- Read the client’s world before the codebase. A guidance page taught me more about the product than merely code.
- Test like a user who isn’t you. Change your phone’s time zone, language and dark mode setting.
- Make bug reports boringly complete. The person reading them may be asleep while you write them.
- Ask about the parts of the system you can’t see. Nobody minds a precise question.
Planning an app that takes bookings?
Diaries, bookings and time zones look simple and rarely are. Lunova Labs designs and builds web and mobile apps (iOS and Android), and if yours handles appointments, the foundations are the part worth getting right first.
Ready when you are