I Spent 56 Hours on This Project. A Third of It Was Wasted.

Ten days. One old website rework. Fifty-six hours of work. And one painful reminder: it’s incredibly easy to spend most of your time on things that don’t actually matter.

This was a solo freelance project. The client had a basic, outdated website from a decade ago. I noticed he was consistently posting project photos and updates on Facebook, so I pitched a new site that would automatically pull his posts and galleries into a clean portfolio. Fully automated. No manual updates. He liked the idea. We kicked it off the next day.

The goal was to give him a simple, modern site where each project had its own page, pulling in text and photos directly from Facebook. He also wanted to list four services. All of it had to stay in sync without him lifting a finger.

I chose Payload CMS + Next.js. I wanted a system that gave me flexibility but also let him make edits if he ever needed to. I had an internal boilerplate for a multitenant SaaS, so I started there—but had to strip it down for a single-client use case.

That’s where things started to spiral.

Time Breakdown

Here’s where the 56 hours actually went:

• 6:09:13 – Writing full seeding logic
• 2:14:00 – Decoupling logic from my multitenant boilerplate
• 12:42:59 – Adding layout templates
• 5:06:16 – Matching those templates to sections
• 8:31:13 – Writing and structuring the site copy
• 5:00:00 – Adding e-commerce logic (which we cut later)

So roughly a third of my time went into templates and logic that I either didn’t end up needing or should’ve approached differently. That part stings.

Where It Went Wrong

I overbuilt the templating system. I thought I needed flexibility, so I created nine layout variations and wired them up to different sections. But by the end, we only used one per section. Every time I changed the data model, I had to go back and update all the templates. Just keeping them in sync became a project of its own.

Same with the seed scripts. I wanted everything to be importable via CSV, so I built a full seeding system to avoid manual entry after schema changes. But I only ever wiped the database once. In most cases, a single table drop would’ve been enough. If I had just created the entries in the admin UI or a spreadsheet, I could’ve saved a full day.

And don’t even get me started on the “color scheme” feature I tried to build into blocks. The idea was to let the user define a global color treatment for each section. In theory, it meant cleaner styling. In practice, it turned into a mess of overrides and edge cases. I ended up replacing it with a simple background color field, and everything worked fine.

What Actually Worked

The stuff that was simple.

Facebook integration was solid. I tackled it early and it didn’t cause issues. The developer app didn’t need to be public. I just invited the client directly and got long-term tokens, which will work for up to 500 clients. That flow alone could be spun into its own product or niche service.

The content structure in Payload also worked once I stopped trying to make it perfect. Services, projects, and blocks were all cleanly defined. When I stopped overthinking flexibility and just built for this client, things moved faster.

What I’d Do Differently

If I were to do this again:

1. Start outside Payload. Build the actual page structure in a plain Next.js project first. Hardcode everything. Don’t worry about a CMS. Just get the visual structure right, with some mock data.

2. Copy production Payload types into that project. This keeps the data structure aligned and avoids constant back-and-forth between UI and templates.

3. Only add one template per section. No more “just in case” templates. If I need more later, I can add them when there’s a reason.

4. Avoid seeding logic unless there’s real complexity. Most small projects won’t benefit from it. Better to populate from the UI or a simple import.

5. Don’t optimize for flexibility in version one. Build what’s needed. If it turns out repetitive, that’s when to extract components.

Final Thoughts

The client is happy. The site looks good and updates itself without his involvement. From a delivery standpoint, this was a win.

But for me, it was a clear reminder that moving fast doesn’t just mean coding quickly. It means not wasting time on what doesn’t matter. Forty percent of this project was me solving problems that didn’t exist yet.

Thanks for reading, Matija