Sign in Subscribe

Building a Digital Logbook: Architecture and First Steps

Last updated on 
Building a Digital Logbook: Architecture and First Steps
Photo by Prince Prajapati / Unsplash

Problem/Why

I love working on my car, but I'm terrible at keeping track of what I've done, when I did it, and which parts I've used. Since I bought the car, I've changed the oil and oil filter, as well as the front and rear brakes, and replaced the caskets for the rocker cover and the sump. I've also done a variety of other small maintenance tasks.
Can I tell you exactly when I did those things? Not really — somewhere between buying the car and today.

Sound familiar? Keeping track of car maintenance can be tricky. So, as with most modern problems, the instinct is to find an app that does it for you.
But instead of downloading one (which surely already exists), I want to build it myself.
Because it will, at the same time, double as a playground to sharpen my development skills. Since I'm currently away from my hardware and car, it feels like a great project to do instead.

Vision

I've decided to split the project into three phases initially.

Phase 1: Digital logbook replacing paper records

  • A simple app to track service history digitally.

Phase 2: IoT sensors for real-time monitoring

  • Add real-time monitoring from sensors, such as GPS and battery voltage.

Phase 3: Predictive maintenance and analytics

  • Use AI/ML to analyse and predict potential issues and maintenance needed.

Let's dive into phase 1 today.

Phase 1: Digital logbook MVP

I've had this idea for some time and tried a couple of times, but never gotten far with it.
What's different this time? Honestly, not much — except that I'm away from my hardware and car, so I finally have the focus and time to stick with it. I'm also keeping the scope deliberately tight and giving myself a time boundary to get something working.

For the MVP (minimum viable product), I'm thinking:

  • Vehicle registration (make, model, year, VIN, etc.).
  • Recording service events (oil change, inspection, repair, etc.).
  • Associating parts with service records.
  • A mobile-first interface.
  • A secure backend API.
  • Containerised deployment for portability.

Stretch goals for Phase 1 include adding photo uploads for service records, setting reminders for upcoming maintenance, and exporting data to CSV/PDF.

Architecture

With such a simple app to begin with, the architecture won't be complicated. But later, the API and DB will need to accept telemetry data.

┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│  Web/Mobile App │◄──►│     REST API     │◄──►│    Database     │
└─────────────────┘    └──────────────────┘    └─────────────────┘

Tech Stack Rationale: Boring Technology

I do like this notion of choosing boring technology, and that's what I'm following in this project. I'm choosing technology I'm familiar with and have used before. The exception is mobile development—since I haven't done that before, that's one of my innovation tokens.

Go

Performant, strongly typed, and something I've used successfully in a production microservice. I've used Python before for personal projects, but not professionally or for app development. I've also used C# professionally, but not as appealing for this project.

Chi

I've used Gorilla Mux before, but seeing that the project hasn't been maintained lately, I thought it was a good opportunity to try something new. I mainly went for Chi since it's lightweight and compatible with the standard library. It felt like a low-friction choice and struck the right balance of simplicity and functionality for this project.

REST API

The simplest and most straightforward approach to start with. I've developed several REST APIs and am comfortable with them. Other patterns (such as gRPC, GraphQL, or WebSocket) might be suitable for future phases or features, but for now, REST keeps things simple.

PostgreSQL

A robust relational database that I'm familiar with. NoSQL could have been a valid option, especially since I plan to add various IoT devices later. However, I haven't used a NoSQL database before, and PostgreSQL has the option to add time-series handling for sensor data later.

Flutter

This is the area where I've never used anything before, so everything is relatively new for me. I've tried to do something with React Native a couple of times, but never really stuck, so I wanted to try something else now and was looking for a cross-platform solution (iOS + Android) with a clean UI.

Podman

I've used Docker before and am comfortable with it, but I wanted to try something else, especially after reading the article "Why I Ditched Docker for Podman (And You Should Too)," which highlighted the benefits of Podman, including daemonless, rootless containers and more. The best part: it's practically a drop-in replacement — just swap docker for podman in the commands.

JWT authentication

A simple, standard, scalable way to support multiple users securely beyond just the basic one. Might later move to OAuth.

Current Status

  • ✅ Initialised Go project with the Chi framework
  • ✅ Implemented DB schema with migrations for users, vehicles, service_records, parts
  • ✅ PostgreSQL running in Podman container
  • ✅ Basic configuration management and health check endpoint
  • ✅ Vehicle and service record CRUD operations

Next Steps

This Week:

  • Implement JWT-based authentication and auth endpoints
  • Wire up Swagger/OpenAPI
  • Begin Flutter mobile app structure

I'll be documenting the entire process — from a CRUD app to an IoT platform — including the architectural decisions, dead ends, and small breakthroughs along the way.

If this sounds interesting, stick around:

  • GitHub repo: [coming soon]
  • Connect with me on LinkedIn if you're working on similar automotive or IoT projects