I just came home from a hangout with my best mates. We met at the beginning of our high school days in an extracurricular called pencak silat, and we’ve hung out ever since. Anyway, one of them owns a car dealership, and I’ve been meaning to help him build a platform to make it easier to manage his car inventory and track sales. Possibly also to track additional finance-related stuff — e.g., employee salaries, etc.

Without getting too into detail, it was getting late, and I wanted to talk about what our current activities were. Funny, right? Usually, you’d start off with that. But I’m sure you guys know that when you hang out, the conversations are far from serious. Well, maybe that’s the exception rather than the norm, but I guess our friend group’s just pretty goofy. Not saying we never talk about serious stuff — just that it’s usually more casual. Hangouts are our way to get the stress off our systems after a long day of work.

Shoot, I went too far into detail. My bad. So, coming back to what I said earlier — I finally decided to ask him. I’d held myself back from bringing it up before because I was afraid I wouldn’t be committed enough to ship it, since I already had a few other projects besides work that were eating up my time. I haven’t even factored in time to spend with my family. But this time, I decided to go for it.

I started by asking him a question I usually ask my “clients” when starting a new project: “Walk me through how you’d bla bla bla.” From this, I start to understand their flow and how I can adapt and integrate the platform into it.

In this context, I asked him to explain the process of buying a car. Notice that I started at the very, very, very beginning — before even selling. I went into every detail: where he gets the information about cars available for purchase, from whom, how he contacts them, how he tracks purchases, etc. It might seem excessive, but it’s better to come prepared and not need it than to need it later and not have it.

We went through loops of the main flow, then level-two depth details, then deeper, and deeper. After that, I got a good understanding of the overall process. Then I continued with the technical stuff.

Before talking about the next process, I’d like to share a bit about my mindset when creating software. I like to consider myself similar to a barber — the customer often doesn’t fully understand what they want. Best case, they do and can tell you exactly how many centimeters (cuz f#k inches*) (I’m joking) they want off the top and sides. Average case, they show you a picture. Worst case, they just say, “Make it better” or “Rapihin” in Bahasa Indonesia (this ain’t ChatGPT :skull:).

So you’re the one who has to expand upon their minimal requirements on your own. From a single sentence like “I want to add a car” to an actual working feature. How’s the backend logic going to look? What should the UI look like? How about the car data model? Wouldn’t I need another data model for the user as its owner? Maybe others for its type and brand? And then a million other questions you’ll have to answer.

Yeah. Tiresome, right? Welcome to software engineering.

All that aside, I realized that even through these tiring processes, I still really enjoy it. It’s because of that that I know this is my passion — my calling. I might want to make another article just about that.

Anyway, I jotted down the features for an MVP, asked him for feedback, made corrections, and repeated the process. It went pretty quickly. Then, I started planning the basic APIs based on the flow. For example, when purchasing a car, an employee would create a car object with certain properties indicating it was purchased — so, a Create Car API. Then it would be updated when moved to the repair stage — Update Car API — and so on and so forth.

Quick note before I forget: the main flow of his dealership is purchase → repair → sell (might not want to explain this). Naturally, this still doesn’t include the authorization and authentication flow, which is complex in its own right and will be developed later — probably in a future devlog. The next step in the process would be creating the class diagram using dbdiagram.io, which I’ve reserved for another day.

Okay, this looks more like a diary than a devlog. Are devlogs usually like this? Or are they supposed to be more technical? I honestly have no clue. Let me know in the comments below. Oh wait — I forgot, I haven’t implemented that yet.