Reflections after building my first WordPress site
Today I launched my first real website for a client. By “real” I mean a website that at least a few dozen people will use each year, and by “client” I mean my sister.
The site is tavacibrighamcity.com.
It’s a simple “brochure”-style website, but it’s an enormous milestone for me: I actually shipped something on my own.
It was ugly, though. I dragged the project out for over two years. I have never done that much overthinking in my life.
My original vision for the site was to be a full-scale student management system, where users could register their children for TaVaci and pay balances, and teachers could use it to take roll call in class.
I had just read Clean Architecture by Robert C. Martin, so I tried to follow his model for a while. Then, after the excitement quickly faded and I realized how much time it was going to take, I started to reconsider.
On the technology side, I did the following:
- Learned the basics of FireBase and FireStore, and built data models for the site in FireStore
- Set up a relational database for the site in Supabase, which uses PostgreSQL
- Set up an AirTable space for the site, as an attempt to use the AirTable API as the back end
- Got basic reads and writes working from the app to a Google Sheet
- Started building the site using Remix
- Started building the site using Astro
- Built the registration form multiple times
- Tried out WordPress
- Tried going full no-code WordPress, including signing paying for a license for the Formidable Forms plugin
- Started building the registration form using the Formidable Forms plugin
- Went back to Astro
- Tried TailwindCSS
- Went back to SCSS
- Went back to WordPress so Megan could control the content
- Learned how to build a WordPress theme
- Finally stuck with the direction and finished the site
Lessons Learned
I learned a few lessons from this experience that I don’t want to forget.
Focus on the part your client cares about
When the client for this project first asked me about rebuilding the site, she had a shortlist of specific things she wanted:
- A site that looks better in general, but especially on phones
- A better annual registration experience for parents of students
- Specifically, a way for parents to see how many slots are left in classes while they’re registering
I was able to deliver on the first two items just by improving the information architecture and user experience of the site. The last item turned out to be really difficult to achieve, and I still haven’t delivered on it. More details on this in the section on client autonomy below.
Part of the reason it took me so long to finish the project was that I secretly added my own list of things I wanted the site to do:
- Allow parents to view their balance and make payments
- Allow parents to re-register their children for the next year without changing anything besides their grade and TaVaci class
- Dark mode
- Allow teachers to take roll using the site
- Make it easier for parents to register multiple children
I spent so much time thinking about the items in my own list that it was frustrating every time I touched base with Megan. I would update her on the things I was architecting, and she would update me on things she needed, and the two almost never overlapped.
My lesson learned here is to only focus on exactly what the client wants, and nothing extra.
Inverse relationship between advanced features and flexibility
One of the pain points of the existing registration experience was the registration form. It was (and still is at the time of writing) a Google Form. Because of the limitations of Google Forms and how the form data are stored in Google Sheets, the only way to allow a parent to register multiple children in one session is to just include a bunch of duplicate questions for child 2, 3, and 4.
One improvement I explored was to hand-code a form that sends data to the Google Sheet just like the Google Form does. That would allow me to let parents add children to the registration dynamically. When I went to share this approach with the client, they said, “Oh yeah, and about the form, I need to add an extra question just for this school year.”
And at that moment I realized that as soon as we moved the form away from Google Forms to a custom-built form, my client would lose flexibility and autonomy. They would have to ask me to change code every time they needed to add a one-off question.
When you add advanced features and customizations, you lose flexibility and autonomy for your client.
Choose boring technology
While I was building the site, one of my co-workers shared boringtechnology.club with me, which influenced me to settle on WordPress as the tool of choice for building the site.
It’s really fun to tinker with bleeding-edge technologies. But for my personality type, it can turn into a distraction from the original goal of finishing the project. I thrive when I’m learning new things, and it’s easy for me to let my learning overshadow the project itself.
Another reason choosing boring technology can be helpful is because it reduces the amount of unknown unknowns in a project. Especially if the boring technology is well-known, it’s likely that any problem I need to solve for my project has already been solved by someone else using the technology.
Fast is better than great
I swear I need to get this tattooed onto my forehead.
Every time I work on a project, I always overthink it and spend too much time trying to get it perfect on the first try. But the reality is that it’ll never be perfect anyway. And even if I lower the bar from “perfect” to “good” or “right,” it’s virtually impossible to hit the mark on the first try.
Here’s another way of looking at it. I’m 100% going to fail, and then I’ll iterate after learning from the failure. So if I’m going to fail anyway, why should I delay it? Why spend time overthinking if I’m bound to be wrong anyway? My path to success will be much more direct if I fail as fast as possible.
So there it is! Those are my thoughts after building my first WordPress site.