At Warrimoo, we build offline-first. Here’s why, and what we’ve learned from the experience.
When we started building TreatMyPet, we made a deliberate choice: the app would work entirely on-device, with no account required, no cloud sync, and no data leaving the user’s phone.
This wasn’t a technical limitation — it was a design philosophy driven by three beliefs:
A privacy policy is a promise. An offline-first architecture is a guarantee.
When your pet’s health data never leaves your device, there’s nothing to breach, nothing to sell, and nothing to subpoena. You don’t need to trust us with your data because we never have it in the first place.
Pet emergencies don’t wait for good reception. You might need your pet’s medication history at a rural vet clinic, in a car on the way to the emergency hospital, or at a property with no mobile coverage.
Offline-first means the app works everywhere, every time, instantly. No loading spinners, no “connection lost” banners, no degraded experience.
Not every app needs an account. Not every feature needs analytics. Not every interaction needs to be tracked, measured, and optimised.
Sometimes the most respectful thing you can do for your users is to simply give them a tool that works and then get out of the way.
Let’s be honest about what you give up:
No cross-device sync — your data lives on one device. We mitigate this with local backup and export features, but it’s a genuine limitation.
No collaborative features — without a server, there’s no way for two users to share data in real-time. For a personal pet care app this is fine; for other products it might be a dealbreaker.
No server-side intelligence — we can’t run analytics, personalise recommendations, or improve the product based on aggregate usage data. We have to get the product right through design and user feedback, not A/B testing.
Recovery is harder — if you lose your phone without a backup, your data is gone. Cloud-synced apps have an advantage here.
Building offline-first forces you to think differently about data architecture. A few lessons:
Design your data model carefully — you can’t easily migrate schemas when the database lives on millions of individual devices. Get it right early, and design for forwards compatibility.
Give users control over their data — export, backup, and import aren’t afterthoughts. They’re core features. Your users should always be able to get their data out in a useful format.
Performance is a feature — when everything is local, the app can be genuinely instant. No network latency, no loading states, no optimistic UI tricks. This sets a user expectation that you need to maintain.
Test on real devices — simulators don’t tell you what a three-year-old phone with 2GB of RAM and a fragmented filesystem will do with your local database.
It depends on your product and your values. But I’d encourage more developers to at least consider it. The cloud-first default isn’t always the right choice, and the trade-offs of offline-first are often less severe than people assume.
Your users will appreciate an app that just works — no account, no internet, no excuses.
]]>A chatbot responds to your input with text. An agent does something about it.
The distinction comes down to three capabilities that a basic language model doesn’t have on its own:
When you combine a large language model with these three capabilities, you get something qualitatively different from a chat interface. You get a system that can reason about a goal, figure out what actions to take, execute those actions, observe the results, and adjust its approach.
Consider something simple: “Find me the cheapest flight from Sydney to Melbourne next Friday.”
A chatbot might tell you which airlines fly that route and suggest you check their websites.
An agent could search multiple booking APIs, compare prices, filter by your preferences (direct flights only, departure after 9am), and present you with actual options — or even book one if you’ve authorised it to do so.
The difference isn’t intelligence — it’s agency. The ability to act on the world rather than just describe it.
Most agent systems follow a loop that looks something like this:
Observe → Think → Act → Observe → Think → Act → ...
In practice:
while not goal_achieved:
observation = perceive(environment)
plan = reason(observation, goal, memory)
action = select_action(plan, available_tools)
result = execute(action)
memory.update(result)
The language model handles the “Think” step — it decides what to do next based on what it knows. The tools handle the “Act” step. And the loop continues until the goal is met or the agent decides it can’t proceed.
After building with and observing various agent systems, here’s where I see genuine value:
Code generation and refactoring — agents that can read codebases, write code, run tests, and iterate based on results. This is arguably the most mature agent use case today.
Research and analysis — agents that can search multiple sources, cross-reference information, and synthesise findings. The key is that they can follow threads that a single query wouldn’t uncover.
Workflow automation — agents that handle multi-step business processes, making decisions at each step based on context. Think: triaging support tickets, processing invoices, managing approvals.
Anything requiring genuine understanding of consequences — agents are confident actors, which makes them dangerous when the stakes are high. A human should always be in the loop for decisions that are expensive to reverse.
Long-horizon planning — current agents are much better at tactical execution (do this, then this, then this) than strategic planning. They can follow a plan, but generating a genuinely good plan for a complex problem is still hard.
Reliability at scale — when an agent needs to perform the same task thousands of times with high consistency, the stochastic nature of language models becomes a liability. Sometimes you just need deterministic code.
AI agents are a real and useful technology. They’re not magic, and they’re not going to replace human judgment any time soon. What they do is extend what a single person can accomplish — they’re leverage, not replacement.
The best agent systems I’ve seen are the ones that stay humble: they do what they’re good at, they ask for help when they’re uncertain, and they keep a human informed about what they’re doing and why.
That’s the kind of agent I want to build with. More on that in future posts.
]]>In a world of tweets and threads, there’s still something valuable about long-form writing. A blog post gives you room to think through an idea properly, to show your working, and to come back and update your thinking as you learn more.
I’ve been building software for a while now, and more recently building Warrimoo and TreatMyPet. Along the way, I keep running into ideas and observations that deserve more than a passing thought — and this is where they’ll live.
This blog will cover a few broad areas:
This blog itself is built with Jekyll and hosted on GitHub Pages. Posts are written in Markdown, which means I can focus on writing rather than fiddling with a CMS. The design matches the main Warrimoo site — warm coastal colours, clean typography, and hopefully a pleasant reading experience.
If you want to follow along, there’s an RSS feed for those of us who still appreciate that sort of thing.
See you in the next post.
]]>