Reducing Friction: How I Built a Content Platform in a Weekend
Friction kills personal projects, not lack of skill. Here's how I used AI tools, Astro, and Tailwind to go from idea to live content platform in a weekend.
The Idea That Never Ships
You’ve had the idea sitting in the back of your head for months, maybe years. You know what you want to build. You can picture the finished thing. But every time you sit down to actually start, there’s something in the way. Not a lack of skill or motivation, but an endless pile of setup, decisions, subscriptions, and boilerplate that needs to happen before you can do the work you actually care about.
You tell yourself you’ll get to it this weekend. The weekend comes. You spend four hours setting up hosting, configuring a CMS, wrestling with some obscure plugin issue, and by Sunday evening you’ve made progress on the infrastructure but haven’t created a single piece of actual content. The motivation quietly drains away. By next weekend, something else has your attention.
If that sounds familiar, this is for you. I’ve lived that loop for years. I’m not going to tell you I’ve solved it permanently, because for larger projects and long-term goals, you’re still going to need to show up regularly and put the hours in. But I have found a strategy that’s making a real difference, and it starts with understanding what’s actually slowing you down.
What Is Friction?
Friction: the accumulated resistance between having an idea and executing on it. It’s every decision, every tool, every hour of repetitive work, every subscription you have to justify. All of it stacks up between you and the thing you’re actually trying to make.
Development is one of my main skill sets. It’s a core part of what I do professionally. But the relationship I have with it is similar to a builder’s relationship with construction. A builder doesn’t build a house because they love laying bricks. They build it because someone needs a house. The goal is the result, not the work itself. That’s how I think about development: it’s a means to an end.
The goal here was never to build a website for the sake of building one. It was to have a platform for content. The website is just what I need in order to get there.
I could have used an off-the-shelf template or an existing platform. And honestly, if I’d found something that matched what I had in mind, I probably would have. But there are a couple of reasons I didn’t. First, I have a specific vision for how I want this to look and feel. Most creators do. You want something that feels like yours, not a generic template that looks like everyone else’s blog. Even with an off-the-shelf solution, you’d end up tweaking it, customising it, working around its limitations. That’s its own kind of friction.
Second, and this is a core value for me: I want to own my own data. I don’t want to be entirely dependent on someone else’s platform where terms of service can change, companies can pivot, pricing models can shift, or features can be removed. Online tools today might introduce restrictions tomorrow. Paid platforms might change what’s included in your tier. When your content and infrastructure live on systems you control, that’s one less source of friction and uncertainty in the long run. (This is one of my core values, and it shapes a lot of my decisions.)
So I built it. Not because I’m attached to the process of building, but because the friction of building something custom has dropped so low that it was actually the fastest path to getting what I wanted, on my terms.
ud83dudca1 Friction isn’t one thing. It’s technical, creative, financial, and emotional, all stacking up at once. And it compounds. Every small blocker adds to the pile until the whole project feels heavier than it should.
Three Types of Friction (in This Context)
There are obviously many kinds of friction. These are the three that were standing between me and getting this content platform off the ground.
Before I get into them, it’s worth acknowledging something about personal projects specifically. Most of the time, there’s no immediate monetary return. There might be one eventually, but it’s months or years away. For this project, any revenue would likely come through consultancy work that the content helps generate, not from the content itself. Content creation is a means to an end: growing a brand, finding clients, building credibility. But right now, it’s just a personal project with no income attached.
That changes the equation for every kind of friction. Every hour you spend is time you’re not billing for. Every subscription is money going out with nothing coming back. It’s like spending a weekend building a piece of furniture. There’s value in the result, but it’s not a profitable enterprise. And if there’s a chance you might decide not to continue six months from now, you really don’t want to have sunk weeks of time and hundreds of pounds into the setup. That front-loaded cost, both in time and money, is a kind of technical and financial debt that makes it harder to even start.
Time Friction
I’ve been working with WordPress professionally since around 2013. I know the ecosystem well. But from real client timesheets, a nicely designed WordPress site with integrations, responsive layouts, and content management averages around 40 hours of work. That’s with experience. That’s knowing exactly what I’m doing.
Forty hours is a lot to invest in something that’s just the container for your content. The website isn’t the product. The content is the product. But if the website takes a month of evenings, you’ve burned through your motivation window before writing a single word.
Then there’s the ongoing maintenance. Plugin updates, security patches, PHP compatibility, user account management. WordPress is a living system that needs attention even when you’re not building.
Financial Friction
Starting a content platform from zero, the SaaS subscriptions add up fast. Social scheduling tools like Hootsuite. Design tools like Figma. Email marketing through Mailchimp. SEO plugins. Premium themes. Managed hosting with the specs that WordPress needs.
Individually, each one seems reasonable. Together, you’re looking at a meaningful monthly cost, and you’re making zero revenue. Hard to justify that overhead for a personal project that might not go anywhere. And SaaS pricing tends to scale as you grow, so the costs compound over time.
The alternative, if you have the technical ability, is free and open-source tooling. Docker Compose files that spin up your entire stack. GitHub Actions for deployment. Static site generators that don’t need managed hosting. The friction drops dramatically when you’re not paying for permission to create.
It’s worth noting that even free tools aren’t always free forever. Platforms that start out with generous free tiers have a habit of introducing restrictions or paid options as they grow. There’s nothing inherently wrong with that, it’s how businesses work. But it’s another reason to think carefully about where your dependencies are and how much control you’re handing over. If you don’t have the technical skills to self-host, these tools still reduce friction significantly. But if you do have those skills, leaning on open-source and self-hosted options gives you one less thing that can change underneath you.
Cognitive Friction
There’s a limit to how many things you can focus on well at any given time. For me right now, it’s roughly three: a house renovation, freelance client work, and this content project. That’s the bandwidth. Everything else gets squeezed.
I’ve noticed this with health and diet, actually. When I’m motivated and focused, I can make solid progress. But the moment another priority takes over, it falls off completely. Not because I’ve stopped caring, but because there’s only so much decision-making energy in a day.
It’s the same reason meal prep companies exist. The food isn’t always amazing, but it removes the friction of planning, shopping, and cooking when you’re already stretched thin. You’re outsourcing the brainpower so you can put it somewhere else.
AI tools for content creation work on the same principle. You’re not outsourcing the thinking. You’re outsourcing the labour of turning your thinking into a finished product.
🔧 Every tool is bought for its outcome. Meal prep saves you from decision fatigue around food. AI tools save you from repeating work you’ve already mastered. The result is the same: more capacity for the things that actually move the needle.
The Website Is a Means to an End
The site you’re reading this on is built with Astro for the framework, Tailwind CSS for styling, Page CMS for content management, and GitHub with GitHub Actions for hosting and deployment. I used Codex (OpenAI) for code generation. The whole thing took under six hours of actual work.
Why Astro
I’ve used static site generators before. My previous go-to was Hugo, which is excellent for straightforward blogging. It’s fast, reliable, and does that job well. But I found it somewhat limiting once I wanted to go beyond a standard blog layout. A lot of what I’m building involves landing pages with dynamic content sections, featured articles, newsletter sign-ups, that kind of thing. More of a marketing or brochure-style site than a pure blog.
Hugo can do some of that, but it starts to feel like you’re working against the tool rather than with it. The Go templating language has its quirks, and I found the documentation could be difficult to follow for more complex page structures. I got it working, but looking at the final result, a lot of it felt somewhat hacky, especially around creating custom sections within pages. It was designed for blogging, and it’s great at that. I wouldn’t reach for it to build a brochure-style site or anything with more complex page layouts.
Astro bridges the gap between a static site generator and something more like a full framework. I can build reusable components and use them across the site the same way I would if I were building a premium marketing site. But it still outputs static HTML, so you get all the performance and security benefits of a static site. It has solid CMS integrations, built-in image optimisation, and it’s clearly been designed with this kind of use case in mind: developers who want the flexibility of a framework without the overhead of a full dynamic application.
When you combine Astro with Page CMS and a GitHub deployment pipeline, the ongoing overhead is essentially zero. Push content, it builds, it’s live. In theory, you could hand this setup to a client and they could update blog posts and events through Page CMS without touching any code. I haven’t fully tested that workflow yet, but the foundation is there. For now, I’m using Codex to create and update components directly, which is fast enough that I don’t feel the need for a more complex editing setup.
I’m not criticising Hugo. It has its place and it’s very good at what it does. But for the kind of site I’m building, Astro feels like the right tool. It’s built on solid fundamentals around performance, static-first architecture, and progressive enhancement with dynamic components where you need them. That matters to me as someone who cares about performance and security.
Tailwind: Solved Problems Stay Solved
Tailwind deserves its own mention because it’s a friction reducer that existed well before AI tools became mainstream. The default colour palettes, the spacing scale, the responsive breakpoints, and especially the Typography (Prose) plugin that handles all long-form content styling automatically. These are solved problems. Use the defaults, move on, focus on what differentiates your site.
But the website itself isn’t really the point of this article. If something off-the-shelf had matched my vision, I would have used it without hesitation. The point is that the friction to build something custom has dropped so low that it barely registers as a cost anymore. Under six hours, and the result looks better than a downloaded template because I could invest time in the parts that actually matter rather than grinding through boilerplate.
How I Actually Work With AI
I’ve been using AI throughout this entire process, from building the site to writing this article. It’s not really a case of “what AI did versus what I did” because the two are intertwined. It’s more like a workflow where I’m guiding the direction and the AI handles the implementation.
The most important thing I’ve learned is that you need to set up a framework before you start. For the site build, the first thing I did was create a style guide and a set of specific instructions for how I wanted the application architected. Use these components. Use these standard styles. Write them as reusable classes so they can be applied consistently across the site. When you build a new section, use the existing components rather than creating something from scratch.
Without that kind of upfront structure, what tends to happen is the AI creates loads of separate components, each with their own unique styles and inline classes. Everything looks fine on the surface, but then when you want to make a change, you find yourself jumping across different files fixing what is essentially the same issue in ten different places because nothing is standardised. If instead you define a component where you can pass parameters like style equals “primary” or “secondary,” and the AI knows to use that pattern, the output is dramatically more consistent and maintainable.
You can save these instructions as reusable skills or templates, so you don’t have to provide the same guidelines every time you start a new session. That framework becomes the foundation. Once it’s in place, you’re not micromanaging every prompt. You’re guiding the overall direction and the AI fills in the implementation details within the boundaries you’ve set.
Here’s how I think about the underlying work. When you learn a process and repeat it regularly, say for a month, by the end you have something repeatable. You understand it well enough to explain it, delegate it, or have an AI tool execute it to a predictable standard. Setting up a form flow from validation through to submission and email delivery, that requires real knowledge. But once you have that knowledge, the implementation is just repetition. And repetitive processes that stack up are exactly what creates friction. Each one on its own is small. But when you have to do all of them yourself, they push you further from your actual goal even though they’re technically part of the path toward it.
This Doesn’t Replace Expertise
This is important, so I want to be direct about it. AI tools don’t replace knowing what you’re doing. They amplify existing expertise.
At a fundamental level, large language models work by predicting the next token in a sequence. They’re trying to give you what they think you want based on your input. If you don’t provide the right guidance, or if you’re not experienced enough to recognise when the output has gone off track, it’s very easy for things to go sideways. The AI will produce something that looks good on the surface, looks like it’s working. But underneath, it might have taken a convoluted approach because it went down a specific path and didn’t know to step back and try a different route. Unless you prompt it to.
If you don’t have the expertise to identify those problems, you can end up with something that appears functional but is fragile, poorly structured, or just wrong in ways you can’t see. It’s the same reason I wouldn’t use an AI tool to try to diagnose a medical issue. My prompt and its prediction aren’t going to reliably get me the right answer, and acting on a wrong answer could do more harm than good.
I’m only using AI in areas where I’m confident I could do the work myself. I can review what it produces and know whether it’s on the right track. That’s not a limitation of the tool. That’s just being responsible about where you apply it.
What this changes is your role in the process. Instead of getting bogged down in implementation details for hours, you can step back and take a more architectural view. You think about the bigger picture, the overall structure, the user experience, while steering the tools to handle the execution. You spend less time as an implementer and more time as a decision-maker. That doesn’t mean you never dig into the detail. You absolutely need to check that the right libraries are being used, that everything is tested, that the output actually works. But you can move between the high-level and the low-level much more fluidly, because the implementation work doesn’t consume your entire session.
The practical result is that when you do sit down to work, you get a lot more done. It might still take you just as long to find the time, to clear your evening, to get into the headspace. Life doesn’t change. But the output per session goes up dramatically. That’s what I mean by roughly 10x the speed to delivery. Not that everything is instant, but that each working session produces meaningfully more progress. You rack up small wins faster. And small wins are what keep motivation alive.
💬 If you could type at the speed of thought, you would. If speaking is faster than typing and the idea is the same either way, you’d speak. AI is just the current best version of closing that gap between what’s in your head and what’s built. But the thinking still has to be yours.
Unlocking What Was Already There
I want to be careful with how I frame this, because I don’t think AI has made me more creative exactly. The ideas were already there. I already knew what I wanted to build and what features would make it better. What’s changed is that the cost of acting on those ideas has dropped to the point where it actually makes sense to do it.
Here’s a concrete example. There’s a stats section on the homepage that pulls data from around five different APIs, collates it, and displays it in a unified view. It runs at build time so it doesn’t query APIs on every page load. It’s a genuinely nice feature.
I would never have built that by hand for a personal project. Writing all the API integration code, the data mapping, the formatting, the error handling, that’s hours of work for what’s essentially a “nice to have.” On a client project you’d justify it because someone is paying for it. On your own blog, you’d skip it and move on to something more essential.
But with AI, I could describe the data structure and get back all the boilerplate mapping and formatting code in a single prompt. The marginal cost dropped so low that it became worth doing. Features that would have been cut for pragmatic reasons are suddenly feasible.
And here’s the part that I think matters most for quality. There’s a paradox in using AI as a shortcut: it can actually lead to you doing things more properly. When the time it takes to implement something the right way drops significantly, you stop cutting corners. Previously, you might have skipped writing proper error handling or taken a simpler but less robust approach because the “proper” version would have taken another two hours you didn’t have. Now the proper version takes fifteen minutes. So you just do it.
Less time on repetitive delivery, more time on testing, QA, and getting things right. The total effort is roughly the same. But it’s distributed differently. The result is actually better quality, not lower, because you can afford to do things properly within the same time window you had before.
ud83cudfaf The creativity was already there. The implementation cost was just too high to justify on a personal project. Lower the cost, and suddenly you can build the thing you always pictured.
Reducing Writing Friction Too
I’m not a natural writer. I understand that writing is necessary for what I’m trying to build, and that’s why I’m doing it. But it’s not where my passion lives. Left to my own process, I’d make some bullet points, tell myself I’d flesh them out later, then never get around to it because the effort of sitting down to write 2,000 words from scratch was always just slightly more than my available motivation.
So I changed the process. This article started as me talking, literally speaking into an AI tool across several sessions, stream of consciousness. The tool transcribed everything. I reviewed the notes. And now I’m refining it into something publishable.
It’s a bit like how executives used to dictate letters to secretaries, except the AI can also ask questions, suggest structure, and point out gaps in your thinking. It’s a collaborator, not just a transcriber.
That matters more than you might expect when you work alone. As a freelancer, I don’t have colleagues to bounce ideas off. And I don’t want to constantly ask friends for feedback on things that aren’t really their area. It’s not what the friendship is for. AI fills that sounding-board role without any social cost, and without it, I think the friction of doing all this solo would have been too high for me to start.
Writers have existed long before AI. They had their own tools and support systems. This is mine.
Everything Is an MVP
This website is an MVP. This channel is an MVP. The workflow I’m using to produce content is an MVP. And that’s deliberate.
There’s a philosophy in the solo builder community, I think it comes from Indie Hackers, that boils down to always be shipping. Don’t let perfect be the enemy of shipped. Get it out there, iterate, learn.
I could have spent weeks polishing this site. It’s not perfect. It’s all written content, no rich media. But nobody is looking at it yet. The audience doesn’t exist yet. Spending 40 hours on polish for an audience of zero is the definition of misallocated effort.
What matters right now is that the foundation is solid, the site looks presentable, and I have a workflow that makes it genuinely easy to produce content. Voice notes into AI, structured in Notion, refined with Claude, published through GitHub. It doesn’t feel painful. That’s the minimum viable workflow, and it’s working.
The interesting thing is that because the tools made the build so quick, this MVP actually ended up looking better than a standard downloaded blog template. It has a more premium feel. That wouldn’t have been possible at this speed without reducing friction across the board. Normally you’d have to choose between “fast and generic” or “slow and custom.” I got to have both.
ud83dude80 Shipping isn’t about cutting corners. It’s about putting your effort where it matters most at each stage. Right now, that’s content and workflow, not pixel-perfect polish for an audience that doesn’t exist yet.
And I want to be clear about the competence point. I understand the fundamentals deeply. I’ve been building websites and digital products professionally for years. Using tools to move faster doesn’t mean skipping the thinking. It means spending less time on the translation between what I know and what’s built, and more time on the decisions that actually matter.
Wrapping Up
Here’s what this all comes down to.
Friction is the reason most personal projects die. Not a lack of ideas, not a lack of skill. The overhead of getting set up, staying set up, and doing all the repetitive work that sits between you and the thing you actually want to make. It stacks up, it drains your motivation, and eventually the project quietly gets shelved.
The strategy that’s working for me is simple: identify the friction, then reduce it at every level.
Time friction: choose tools that don’t require ongoing maintenance. Build with Astro instead of WordPress. Deploy through GitHub Actions. Use Tailwind’s defaults instead of hand-crafting a design system. Get the site done in hours, not weeks.
Financial friction: lean on free and open-source tools where the quality is good enough. Self-host where you can. Don’t take on monthly subscriptions until the revenue justifies them.
Cognitive friction: outsource the repetitive implementation to AI so your limited focus goes to the decisions that actually matter. Set up frameworks and style guides so the AI produces consistent, maintainable output. Work at the architectural level instead of getting bogged down in the details.
And through all of it: ship it. Ship the MVP, iterate, and don’t wait for perfect.
None of this is revolutionary. But doing all of it together, consistently, has made a real difference. I went from idea to live site to writing my first article in about 36 hours. That wouldn’t have happened a few years ago. The friction would have killed it somewhere around hour 20.
These ideas, reduce friction, own your own data, and ship it, are core values that shape almost every decision I make about tools, platforms, and how I work. I’ll be writing more about each of them separately.
This is the first entry in Let’s Figure It Out. There’s a lot more to figure out. But the friction is low enough now that I can actually get started, and that’s the whole point.
This post was drafted by speaking into an AI assistant across several sessions, then refined into the article you just read. Which is, itself, an example of everything I’ve been talking about.
If any of this resonated with you, if you’re figuring out similar stuff, if you’re curious about the same kinds of tools and ideas, I’d like to hear from you. I’m trying to meet like-minded people, share ideas, and help each other grow. Drop me a message on the Telegram channel (link in the sidebar) and let’s talk.