A long weekend, a personal website, and a real experiment in AI-assisted development
I started my career as a backend/frontend developer. Over time, that shifted toward consulting, solution design, Martech architecture, customer engagement platforms, and everything that sits between business needs and technical execution. I still enjoy that world a lot, and it is where most of my professional energy goes today.
But the part of me that liked opening a code editor and building things never disappeared.
It just had fewer occasions to show up.
So when I found myself with a bit of time, I decided to use it on something both useful and enjoyable. Not a huge side project. Not something so ambitious that it would collapse under its own weight. Just something real enough to matter, but light enough to stay fun.
A personal website felt like the right choice.
Of course, I already had good reasons for wanting one. I wanted a place to collect my articles, which for now mostly live on Medium. I wanted a better home for my bio and professional profile. I wanted something more mine than the usual mix of LinkedIn, Medium, and scattered references.
But if I am honest, those were not the only reasons. They were also the excuse.
The deeper reason was simpler: I wanted to get my hands back on code and see what AI‑assisted development actually feels like when it is properly inside the workflow.
That, more than the website itself, was the real experiment.
Why this project felt right
A personal website sits in a nice middle ground.
It is meaningful enough to care about, but bounded enough not to become an endless technical detour. It gives you real decisions to make about structure, content, tone, layout, and implementation, without forcing you into months of work before anything becomes usable.
That was exactly what I wanted.
I did not want to over-engineer a side project. I wanted to build something concrete, enjoy the process, and see what development feels like when AI is not just an occasional helper, but an active part of the workflow.
In that sense, the site was both a practical asset and a laboratory: a reason to code again, and a reason to observe how much building has changed.
Why I chose Astro
Astro felt like the right fit quickly.
I did not need a heavy application framework, a complex backend, or a lot of moving parts. What I needed was something clean, content-oriented, modern, and flexible enough to grow later.
That is exactly what Astro gave me.
Astro positions itself around content-driven websites and a lighter approach to JavaScript; exactly what I wanted. For a personal site centered on articles, profile, and editorial structure, it struck the right balance between simplicity and modernity: lean enough to keep momentum, but not so minimal that it would feel limiting later.
That mattered because I knew the site would not stay static. More articles will come. More sections may come. More refinement will definitely come. I wanted something that could start clean without feeling temporary.
Why I chose Vercel
I made a practical hosting decision: I chose Vercel mainly because of the smoother experience around custom domain support (Cloudflare does not allow a simple CNAME).
This is not a glamorous choice to write about, but it is exactly the kind of decision that defines real projects. When you are building over a long weekend, friction matters. Setup matters. Unnecessary obstacles matter.
In this case, Vercel simply felt like the more direct path to getting the site online with the domain setup I wanted.
Sometimes the best technical choice is not the one that wins abstract debates. It is the one that keeps the project moving.
The most interesting part: building with Claude Cowork
What made the project genuinely interesting to me was not just building the site. It was building it with Claude Cowork as part of the process.
And I say “part of the process” intentionally.
The most honest description is not “AI built my site.” That is too simplistic, and not very useful. What happened felt much more like working with a very fast implementation partner.
I still made the choices. I still decided what I wanted. I still judged what was good, what was off, and what was coherent. But the distance between idea and first implementation became much shorter.
That changed the rhythm of the project in a very real way.
I could think naturally about what I liked, what I wanted to borrow from another template, what behavior felt right, what would need to scale and ask for help directly from that intent.
That is where the experience became genuinely enjoyable.
Moving features from one template to another
One of the most useful things I did was choose an Astro theme as a base and then use Claude Cowork to bring into it features I had seen in other templates.
That was probably the most realistic part of the whole project.
Real websites are rarely born from one perfect starting point. More often, you find a base you like, then notice elements elsewhere that solve something better: a cleaner article list, a nicer layout pattern, a more elegant section structure, a different navigation behavior.
Normally, stitching those ideas together can be tedious, especially if you do not want to spend hours manually rewiring code.
This is where Claude Cowork was genuinely useful.
It helped me bridge the gap between reference and implementation. Not perfectly, not magically, but quickly enough to keep the creative flow alive. And for a personal project, that matters a lot.
Momentum is everything.
A small example that says a lot: pagination
At one point I realized something obvious: the number of articles is manageable now, but it will grow. So I needed pagination. I did not stop to formalize a specification. I did not write a technical brief. I simply told Claude Cowork something very natural:
“In future the number of articles will grow, so please I need pagination.”
That sentence may sound trivial, but it captures what is most interesting about this new way of working. It was not polished prompt engineering. It was not pseudo-code theater. It was a human request based on a practical need.
And from there, the implementation moved forward.
That is what felt new. The interaction stayed close to intent. I could think in terms of what the site needed, not only in terms of how I had to manually break every problem into syntax-level pieces before getting started.
For someone like me, someone with a developer background, but no longer coding every day as a core professional activity, that was refreshing.
It made building feel accessible again without making it feel fake.
What I enjoyed most
What surprised me most was not speed. It was pleasure.
This project reminded me that I still enjoy making things.
That may sound obvious, but it is not. When your work shifts over the years toward consulting, architecture, client needs, governance, roadmaps, and delivery pressure, the emotional texture of technical work changes. You still solve problems, but at a different layer. You are often one step removed from the tactile side of implementation.
This project gave some of that back.
Not in a nostalgic way. Actually, in a very current way. I was not pretending to go back to being a full-time developer. I was simply rediscovering the satisfaction of building something directly, but with a workflow that felt aligned with where the industry is going.
That was probably the real reward of the whole exercise.
The website itself still matters
Of course, the site is not just a playground.
I genuinely wanted a proper home for my work. My articles mostly live on Medium today, and Medium remains useful. LinkedIn remains useful too. But both are third-party spaces. They are good for reach and conversation, not for ownership.
A personal website is different.
It lets me bring together:
- my articles
- my bio
- my professional profile
- my areas of focus
- the broader thread connecting what I write and what I do
That matters because over time work becomes cumulative. Articles are not just isolated pieces, they form a perspective. A personal site makes that perspective easier to see.
So yes, this started as an excuse to code again. But the output is also strategically useful, and that is part of why the project felt so satisfying.
What AI was good at and what still depended on me
This experience reinforced something I increasingly believe: AI is very good at acceleration, but not at authorship (yet?).
Claude Cowork helped me reduce friction, implement ideas faster, adapt patterns, scaffold functionality, and maintain momentum. But it did not know what kind of site felt right for me, what tone best represented me professionally, which sections felt authentic versus generic, or the difference between technically acceptable and personally right.
Those decisions remained mine.
And that is exactly the point.
The value was not that AI replaced the work. It made the work easier to enter, easier to shape, and easier to continue.
Why this matters for a Martech profile like mine
One thing I like about this experiment is that it was not only about a personal site.
It also reminded me how useful this kind of workflow can be in professional contexts where speed, iteration and autonomy matter.
The real value is not that AI replaces engineering discipline. It is that it shortens the path between idea and proof of concept.
That is especially relevant in Martech and customer engagement environments, where you often need to make something tangible before the normal delivery machinery has time to move.
The same approach could be extremely useful for creating, among other things:
- custom Braze HTML banners
- custom Braze in-app messages
- email templates with more complex personalization logic (Liquid, AMP, Handlerbar, no difference!)
- advanced AMPscript implementations in Salesforce Marketing Cloud
- lightweight cloud functions with Cloudflare Workers or similar tools
Sometimes you do not want to wait for formal prioritization, internal timing, or a full delivery cycle just to test an idea or prove that something is possible. Sometimes you simply need a proof of concept, a prototype, or a concrete artifact that helps a conversation move forward.
That is where this style of AI-assisted building becomes especially interesting.
Not because it removes the need for proper implementation later. Not because it replaces engineering rigor. But because it helps you explore, demonstrate, and prototype much faster.
And honestly, that is one of the reasons this small personal project felt relevant beyond itself.
It was fun, yes. It was personal, yes. But it also felt like a hands-on reminder of how useful this way of working can become in the kinds of Martech environments I deal with every day.
Final thought
If I describe this project in the most functional possible way, the story is simple: I built a personal website with Astro, hosted it on Vercel and used Claude Cowork to help me adapt features and implement pieces more quickly.
That is all true.
But the more honest version is this: I had a long weekend, I missed coding, I wanted to experience what AI-assisted development really feels like in practice, and a personal website became the perfect excuse to do it.
AI does not just help people code faster. It helps people who used to build step back into building again.
Sources and references
Astro official documentation explaining Astro’s positioning as a framework for content-driven websites, with an emphasis on performance and reduced JavaScript overhead.
https://docs.astro.build/en/concepts/why-astro/
Astro Content Collections Official documentation on organizing and scaling content in Astro.
https://docs.astro.build/en/guides/content-collections/
Vercel Adding & Configuring a Custom Domain
Official documentation on attaching and managing custom domains in Vercel.
https://vercel.com/docs/domains/working-with-domains/add-a-domain
Anthropic Claude Cowork
Official product page describing Claude Cowork and its agentic, task-oriented workflow.
https://www.anthropic.com/product/claude-cowork
Adobe Journey Optimizer Personalize Content
Official documentation on personalization capabilities in AJO.
https://experienceleague.adobe.com/en/docs/journey-optimizer/using/content-management/personalization/personalize
Salesforce Marketing Cloud AMPscript Language Basics
Official Salesforce Developers documentation relevant to more advanced dynamic email logic in Marketing Cloud.
https://developer.salesforce.com/docs/marketing/marketing-cloud-ampscript/guide/mc-ampscript-guide-language-basics-for-loops.html
Cloudflare Workers Overview
Official documentation describing Workers as a serverless platform for deploying lightweight edge functions.
https://developers.cloudflare.com/workers/