Sometimes the prep-work is 90% of the work

Development hell is a place of legends, where developers are punished with working on never ending projects. But did you know there’s also a pre-development hell? It’s a place where you get stuck if your project doesn’t manage to take off. That’s where I have been last week (and a little bit before that) with my new project. Every time I thought I’d solved a problem, a new one appeared.

The first roadblock was having to context switch to a new project. That is never fun when you’re neurodivergent because your brain looks at the unstructured new project and thinks “Yeah, I don’t think I want that…”. It is significantly harder when you have been working on the same project for many, many months like I have.

Translating the “requirements” to actual requirements was a chore, especially because the brain wasn’t cooperating. And then came the chore of translating those requirements into an actual technical solution.

The core concept of the project was rather simple. When you drilled down it was just a hand full of models that the app would interact with in a fairly straight-forward way with some small exceptions. The question was more how we’d build the app. The original brief asked for an on-premises solution, which raised security concerns. Building an application with web technology that handles sensitive data in an environment that you don’t control while trying to restrict access to that data is difficult when the on premises location means you’ll never have a full overview of who views the data as there’s always a way to work around your limitations. Direct access to the database? Copying the database? Getting the encryption key from the files?

Since I’m mostly a Laravel developer I didn’t see a clean path to building an on premises app. Updating the app would be a pain and the direct access that network administrators would have to the data could make the app redundant.

I’m aware that there are probably a million ways to isolate apps inside a network. But for every project, there’s restraints. Our restraint for this app was that we don’t have the manpower and resources to build an app that would be fully secure on premises. instead, I pitched an alternative with e traditional web app where the database and encryption keys would be off limits to everyone in an organisation, making the goal to log every action much more achievable. We pivoted to a web app and in a second phase we would build an API around the web app along with native apps for desktop and mobile.

Once that concept was greenlit, I thought I’d found the stack we would use: Laravel, Filament and Flux. The idea was that this stack would help us to build the app fast. But my Mac decided that was a good moment to derail me by refusing to install Node, a requirement for installing FluxUI. Herd”s “Install Node” button didn’t work. Homebrew refused to play nice. The culprit? A relic from the past, an old version of Node that apparently I”d installed on my previous Intel based Mac. This version had been migrated when I migrated my entire Mac to the new one using the wizard but lead to a Node install that couldn’t be overwritten.

Migrating my Mac using the wizard was a mistake. Here’s a lesson for everyone who’s still got to make the step from Intel to Apple Silicon: only migrate your data. The full migration is a trap and any time you think you’ll save with the wizard you’ll lose four-fold or five-fold as apps, tools and terminal start to conspire against you.

The solution was simple, but time consuming. Resetting my Mac and reinstalling all the tools was the way forward, which I did on my day off because I’d been having a few too many “bad days” at work recently so I hadn’t been super productive.

With my Mac sorted out, I ran into a mental roadblock. I planned to start from my “Laravel Starter Repo”, a Github repo I’d been starting my projects from for a while. It comes with some views for user management and some cool artisan commands and usually sped up development a little bit. But this time, I felt like the Starter Repo was too outdated. I haven’t updated it in a while and I considered updating it. But after analyzing the repo, it wasn’t in a good enough spot. Just the user view scaffolding wasn’t worth the head aches it would bring with me, so I copied the useful Artisan commands, wrote a new setup script, added an Artisan Command of about three lines to create the first user and started a new Laravel project using the starter kit.

After rolling the new project and adding the few commands, the setup script and the setup command I was good to go. I added Filament and FluxUI and was ready to start developing.

Or was I? Filament at first felt like a good fit as it’d rapidly setup the CRUD operations for the models, but it soon became a problem on paper. The time gained was negated by the realization that filament wasn’t a fit for our specific needs. It would lead to less transparency of what data we were manipulating and small edits would become medium size problems as we’d have to recreate the resource controllers every single time. The more I thought about it, the more Filament became a nuissance rather than a time saver, so it had to go.

As a result, I tried to save some time by instructing my AI Agent to setup the scaffolding for the new app instead. The API agent happily ate up half of my credits to do so, which wasn’t the main problem. The real problem was that it had entirely made up “best practices” and “requirements” for this scaffolding, adding things to our models and views that made the app needlessly complicated to maintain yet again. Instead of saving time, it made me realize I’d be better off just doing everything myself as it’d be faster than trying to fix the mess it had created.

Don’t get me wrong, AI tools can be great helpers, but they’re terrible lead developers. Anyone who tells you otherwise probably doesn’t know what “responsibility”, “ownershipt” and “security” is.

In the end I skipped the work of my AI Agent and started over. Only to run into an end-of-the-week mess of changes to Livewire, a rude reminder why I’m allergic to most things front end and a painful lesson about how those things build their CSS files. Lessons I’d swear I’d never forget if I was a lying man, which I’m not.

At the end of the week I managed to also overcome *that* problem, but my capacity to read documentation or in fact anything at all had been reduced to nothing. My patience with LLM’s and AI agent had been evaporated. To give you an example of how fried my brain was, I was getting annoyed at some piece of documentation only to realize after an hour that I was reading the documentation for the wrong component in the library. Once I realized that little detail, all the documentation suddenly made sense.

At the end of the week (and past my actual office hours) I finally made some progress on the very first page of the application. Looking at this project, an outsider would think I have been spending almost two weeks to create one form. But the reality is that in order to start coding, all the puzzle pieces have to fit and sometimes that’s easy and sometimes it’s hard.

And yes, I could have probably forced my way through the app by forcing myself to use Filament or throw out the UI library entirely. But if there’s one thing I’ve learned in my “developer” career it’s that preparation is 90% of the work. Getting things right on paper and making sure that your app is easy to maintain, edit and code for is as important as writing the actual code. When you brute force your app in a mold that doesn’t fit, you might get a MVP out of the door faster, but it might cost you more time, resources or your reputation down the road.

The app might not exist in bits and byyes yet, but I’m comfortable to say that all problems have already been worked out on the pre-computer (my brain) which will speed up the development process. So I’m sorry for saying I “was almost done”, boss. Especially because afterwards I had t to announce I’m “starting all over”. But if there’s one thing you’ve taught me it’s that it’s better to build something right than fast.