|
min. read

Developer Case Study: Tristan Drummond & Gideon Boshoff / WorkWeek

Background

Tristan Drummond and Gideon Boshoff joined us to discuss implementing PowerSync for WorkWeek, a time tracking app that allows wage-earning workers to verify time worked, even when they’re on remote sites with no internet connectivity. We spoke about why they decided to follow a local-first approach, the stack they used to build the solution, and what their experience has been like using PowerSync.

App details

App name WorkWeek
Platform(s) Mobile (have a separate dashboard web app)
App framework Flutter (initially FlutterFlow)
Backend API Supabase (PostgREST)
Backend database Supabase (Postgres)

Interview

PowerSync

Why did you decide to follow a local-first architecture for your app?

WorkWeek

Initially, our only need was around offline capability for the app as some of our customers use it on construction sites with poor connectivity. We implemented PowerSync because we didn't want to build [a sync engine] ourselves, and PowerSync met all of our technical requirements. This essentially opened the door to local-first for us.

Since then, we have benefited from other features inherent to local-first architecture. This includes low latency, which ended up being a nice perk even though it wasn't an initial consideration. Secondly, the sync bucket system is also nice and clean, it is such a great approach.

PowerSync

What options did you evaluate for implementing offline-first before choosing PowerSync?

WorkWeek

We didn't really consider any other off-the-shelf solutions. We did initially consider building a custom solution but decided against it as I mentioned before. Only after deciding to go with PowerSync did I investigate other solutions but they were either more complicated, didn't offer a hosted solution, or were closed source.

PowerSync

Why did you choose PowerSync over any other options? More specifically, what is the number one most valuable thing about PowerSync that makes it stand out over other options?

WorkWeek

Time was initially the biggest factor. There was strong customer demand for the app to be able to work offline and you guys helped us understand what resources building a custom solution would take. But I would say the number one most valuable thing was once we gained an understanding of the complexity of the problem, we didn’t have to handle the majority of the complexity, PowerSync did. Another big win was that PowerSync provides a managed service that scales — we didn’t want that as a problem.

PowerSync

Were there any other specific complexities that seemed like a heavy lift that PowerSync solved?

WorkWeek

Getting the right data to the right devices would have been a headache, but luckily PowerSync solves that with Sync Rules. Also, working with the different SDKs makes you realize how much is happening in the background that we would have had to figure out ourselves.

PowerSync

The vision we’re pursuing is to make offline-first or local-first architecture so easy to implement that people prefer implementing it for simplicity as opposed to traditional “cloud-first” architecture where you retrieve data from an API to display in the app.

Do you have any ideas or suggestions for what we should focus on in the product going forward to help us achieve that vision?

WorkWeek

Firstly, that's a great vision for the product and we are both super behind it. I think one of the biggest hurdles for us was because we wanted to deviate our authentication strategy from what is in the documentation, we were immediately in no-man's-land. If the docs supported more use cases it would be easier. So, although I am sure most examples will get covered by the docs, if the idea is to make it as easy as possible I would recommend a push on the educational front on how the product is implemented in different scenarios.

Then, I’m not sure if this necessarily adds to the vision, but something I found to be of great value in the last while was the diagnostics tool. This tool is really helpful to remove the fear of this tech being a black box: I can see what's happening on the local DB, I can see what happens with the sync buckets and I can see what is happening on the backend DB. So, having good resources and having good insight into what's happening makes it a lot easier to just jump on board and get stuck in.

PowerSync

Thanks, that’s great feedback. Is there anything else you’d add?

WorkWeek

Yeah, so we are probably going to build another mobile app soon that probably won't need to function offline and in my mind, the early setup is still more difficult than a cloud-first approach. You can work hard at understanding it all, but then even if you do get close, in my mind there are still a couple of drawbacks. For instance, what happens if you do big schema changes and you want to change some of the SQL code on the device? Then you need to ship over-the-air updates. So there is a bit of risk to having the logic for the backend sit on the client side. I know that you have problems with that in the traditional server-client mentality, but I think maybe I just need to be educated and figure that flow out.

PowerSync

Thanks so much for all this feedback. It was super valuable.

WorkWeek

It's a pleasure. We're super happy and look forward to the next chapter.

Subscribe to receive updates

Thank you! Your submission has been received.
Oops! Something went wrong while submitting the form. Please try again.