I Rebuilt TreqMusic.com in a Weekend With AI. Here’s What I Learned.

This past weekend, I rebuilt treqmusic.com using Cursor, Midjourney, Adobe Firefly, and ChatGPT.

I’ve been building websites for years, so I wasn’t trying to see whether AI could magically create a website for me. I wanted to see how much faster I could move when AI was involved across the entire process: planning, design, development, content, testing, optimization, and launch.

The answer was: a lot faster.

What normally could have turned into a multi-week redesign became a weekend project, and most of the actual build happened in hours. The final site is faster, cleaner, mobile-friendly, SEO-ready, easier to maintain, and much closer to the visual direction I wanted for The Treq.

But the biggest takeaway wasn’t that AI can build websites now.

It’s that AI dramatically reduces the time between having an idea, testing it, changing it, and shipping it.

That changes the way you build.

The Tools I Used

I didn’t use one AI tool for everything. Each tool handled a different part of the workflow.

  • Cursor handled most of the development work. I used it to build and refactor HTML, CSS, and JavaScript, troubleshoot issues, improve responsive behavior, and make changes across the site without manually digging through every file.
  • Midjourney helped me explore visual concepts, artwork, and directions for the site much faster than starting every idea from scratch.
  • Adobe Firefly was useful for refining and generating additional creative assets and variations.
  • ChatGPT helped with planning, reviewing content, SEO, accessibility considerations, troubleshooting, and working through decisions before I handed them off to Cursor.

The important part is that none of these tools were operating independently.

I was constantly moving between them, taking an idea from one tool, testing it in another, reviewing the result, and deciding what stayed.

That’s where the speed came from.

AI Makes Iteration Much Cheaper

This is probably the biggest difference I notice between traditional web development and AI-assisted development.

Without AI, changing direction can become expensive very quickly.

You may spend hours building a layout before deciding it doesn’t work. A new design direction means reworking assets. A mobile issue can lead to another round of CSS changes. A small feature can send you down a documentation rabbit hole.

With AI, I could try something, see it running almost immediately, and decide whether it was worth keeping.

That meant I could:

  • Try different page layouts without rebuilding everything manually.
  • Generate several visual directions before committing to one.
  • Test different navigation approaches.
  • Refactor code that had become too complicated.
  • Ask Cursor to simplify something instead of continuing to pile code on top of it.
  • Change mobile behavior and immediately test the result.
  • Remove features that looked good in theory but didn’t improve the site.
  • Revisit decisions without feeling like I had already invested too much time to change them.

That last point matters.

When experimentation is expensive, you tend to protect work you’ve already done.

When experimentation is cheap, you can be much more willing to say, this isn’t good enough, try something else.

I Chose a Simple Architecture on Purpose

One thing AI development tools are very good at is helping you build complicated things.

That doesn’t mean every project should be complicated.

For TreqMusic, I chose mostly static HTML, CSS, and JavaScript instead of automatically reaching for React, Next.js, or another framework.

That was intentional.

TreqMusic is primarily a music and content site. It needs to look great, load quickly, work well on mobile, make the music easy to find, and be simple to maintain. It doesn’t need a large application framework just because one is available.

For this project, keeping the architecture simple gave me:

  • Faster page loads.
  • Fewer dependencies.
  • Less code to maintain.
  • Easier hosting and deployment.
  • Strong SEO without adding unnecessary complexity.
  • More control over exactly what the browser loads.

If I were building a larger application with authentication, user accounts, dynamic data, APIs, or complex interactive features, I might make a different choice.

That’s one of the lessons I keep coming back to with AI development: AI can make it easier to overbuild things too.

You still need to know what the project actually needs.

The Workflow Was More Important Than the Prompts

There’s a lot of discussion about finding the perfect AI prompt.

That wasn’t what made this project work.

The workflow mattered much more.

I didn’t ask Cursor to “build me a music website” and accept whatever came back. I treated the project the same way I would any other web project, except AI was helping me move much faster through each stage.

My process looked more like this:

1. Decide what the site needs to accomplish

Before touching the code, I defined what I wanted from the site.

For TreqMusic, that meant:

  • Make the music the focus.
  • Create a stronger visual identity.
  • Make the site feel modern without looking like an AI-generated template.
  • Improve mobile usability.
  • Keep navigation simple.
  • Improve performance.
  • Make SEO and accessibility part of the build instead of an afterthought.
  • Avoid unnecessary frameworks and dependencies.
  • Make future updates easier.

That gave the AI something much more useful than “make this look better.”

2. Build and test in small pieces

I didn’t generate the whole site at once.

I worked through individual parts of the experience, tested them in the browser, and then moved on.

For example:

  • Build the navigation.
  • Test it on desktop and mobile.
  • Fix what doesn’t work.
  • Move to the hero area.
  • Add imagery.
  • Check load performance.
  • Build the music sections.
  • Test interaction.
  • Refactor repeated code.
  • Continue.

That keeps mistakes small and makes AI-generated code much easier to manage.

3. Use AI to explore, not decide

Midjourney and Firefly gave me a huge number of visual possibilities very quickly.

Most of them didn’t make it into the site.

That’s normal.

AI is very good at generating options. The human part is deciding which option actually fits the project.

I rejected visuals because they were:

  • Too generic.
  • Too busy.
  • Too dark.
  • Too distracting from the music.
  • Too similar to other AI-generated artwork.
  • Visually impressive but wrong for the brand.

Generating more options doesn’t remove the need for taste. It makes taste more important.

4. Keep asking whether something can be simpler

This became one of the most useful parts of the build.

AI tends to be very willing to add things.

More JavaScript. More CSS. Another animation. Another library. Another component.

Sometimes the better prompt is simply:

Can we do this with less?

I repeatedly used Cursor to:

  • Remove duplicated code.
  • Simplify CSS.
  • Reduce JavaScript.
  • Reuse existing patterns.
  • Remove unnecessary effects.
  • Fix responsive layouts without adding another dependency.
  • Clean up code after several rounds of experimentation.

AI helped write the code, but it was just as valuable when I used it to remove code.

You Still Have to Know When the AI Is Wrong

This is the part that gets lost when people talk about how easy AI makes development.

AI can generate code incredibly quickly.

It can also generate bad code incredibly quickly.

It can tell you something is optimized when it isn’t. It can create accessibility problems. It can add unnecessary libraries. It can break something that was already working. It can confidently recommend an approach that makes no sense for your project.

So I never treat “the AI says it works” as testing.

I still check the actual site.

For a project like this, that means reviewing things like:

  • Mobile and desktop layouts.
  • Navigation.
  • Broken links.
  • Image loading.
  • Page speed.
  • Heading structure.
  • Alt text.
  • Metadata.
  • Social sharing information.
  • Keyboard navigation.
  • Color contrast.
  • JavaScript errors.
  • Layout shifts.
  • HTTPS.
  • Basic security.
  • Search visibility.

Tools like Lighthouse and WAVE are useful because they give you another layer of validation, but they’re still only part of the process.

The real test is whether the site works well for an actual person.

The Real Skill Is Context and Direction

The more I use AI tools, the less I think “prompt engineering” is the interesting part.

You can teach someone a prompt format pretty quickly.

What’s harder is knowing:

  • What problem you’re actually solving.
  • What information the AI needs.
  • What constraints matter.
  • What good output looks like.
  • What to reject.
  • When something is becoming too complicated.
  • When the AI is solving the wrong problem.
  • When to stop iterating and ship.

That’s much closer to how I’ve worked throughout my career in knowledge management, KCS, web development, search, and AI.

Good systems perform better when they have good context.

AI is no different.

If you give it a vague request, it fills in the gaps itself.

Sometimes that works.

Sometimes you get a purple gradient, three unnecessary animations, six JavaScript libraries, and a website that looks exactly like every other AI-generated website.

The better you define the problem, the better AI becomes at helping you solve it.

What I’d Recommend for Someone Building a Site Today

If you want to use AI to build or rebuild a website, I wouldn’t start by asking which AI tool is best.

Start with the project.

For a relatively simple site, I’d keep the process lightweight:

  • Define what the site needs to accomplish.
  • Decide what content and pages actually matter.
  • Choose the simplest architecture that supports those needs.
  • Give your coding AI access to the full project context.
  • Work in small sections instead of generating everything at once.
  • Use image-generation tools for exploration, not automatic final assets.
  • Test constantly in the browser.
  • Review mobile early, not after the desktop version is finished.
  • Check accessibility, SEO, and performance as you build.
  • Refactor after major changes.
  • Remove anything that isn’t improving the experience.

If you’re building something more complex, frameworks like React or Next.js may be the right answer. AI makes those significantly easier to work with too.

Just don’t confuse “AI can build this” with “the project needs this.”

Web Development Isn’t Going Away. The Workflow Is Changing.

I don’t look at this and think designers or developers are suddenly unnecessary.

I think the amount of work one capable person or team can accomplish is changing very quickly.

A developer can prototype more ideas before committing to one.

A designer can explore more visual directions.

A small business can build something that previously required a much larger budget.

An agency can reduce repetitive development work.

And someone who already works across design, development, content, and AI can move between those areas without nearly as much friction.

That’s what impressed me most about rebuilding TreqMusic.

The tools didn’t come up with the direction.

They didn’t decide what was good.

They didn’t understand the brand better than I did.

They helped me move from one decision to the next much faster.

For me, that’s where AI-assisted development gets interesting.

The barrier isn’t really whether you can build something anymore.

The harder question is whether you know what should be built, what good looks like, and how to keep AI moving toward that instead of simply accepting whatever it gives you.