DEV Community: Kristieene Knowles

I Got Tired of Running Lighthouse Manually, So I Automated It

Kristieene Knowles — Fri, 24 Jul 2026 14:13:33 +0000

Lighthouse has been one of those tools I've used throughout my web development journey.

For a small website, running a Lighthouse audit manually isn't really a problem.

Open DevTools, run the audit, look through the results, fix what needs fixing, and move on.

That works perfectly well when you're dealing with a handful of pages.

But Web Weavers World isn't really a handful of pages anymore.

As the site has grown, I've found myself wanting to audit more than just the homepage. There are project pages, showcase pages, tools, experiments, forms, and other parts of the site that can all behave differently.

Running Lighthouse manually across all of those pages gets repetitive very quickly.

So, naturally, I automated it.

The Problem Wasn't Lighthouse

I want to make something clear first: manual Lighthouse testing is still useful.

I haven't built this because I think manually running Lighthouse is somehow bad or outdated.

If I'm working on one page and want to quickly see how it's performing, opening Lighthouse and running an audit is probably still the easiest option.

The problem appears when I want to ask a slightly different question:

"How is the whole website doing?"

Suddenly, testing one page isn't enough.

If a website has 5 pages, manually auditing them isn't particularly painful.

If it has 50, 100, or more URLs, that's a very different workflow.

At that point I'm not really spending my time analysing Lighthouse anymore.

I'm spending my time repeatedly launching Lighthouse.

And repetitive development tasks are increasingly becoming something I look at and think:

"Can I automate this?"

Turning Lighthouse Into a PowerShell Function

My solution was to build a PowerShell Lighthouse auditing function.

Instead of opening each page individually, I can give the function the pages I want to audit and let it work through them for me.

More importantly, I added support for sitemap auditing.

That means I can point it at a site's sitemap, let it collect the URLs, and then run Lighthouse against those pages automatically.

For Web Weavers World, that changes the workflow completely.

Instead of:

Audit page.

Wait.

Save results.

Open next page.

Audit page.

Wait.

Repeat.

I can start one audit and let PowerShell work through the site.

Recently I ran it against my sitemap and watched it pass the 100-page mark.

At that point my PowerShell window started looking slightly like one of those games where hundreds of filenames fly past while something loads.

Except this time it was my website being audited.

Automation Doesn't Mean Ignoring the Results

This is something I've been thinking about quite a lot recently.

I've been automating more of my development workflow, but the goal isn't to remove myself from the process.

It's to remove the repetitive parts.

Lighthouse still decides what it wants to flag.

I still have to decide whether those findings matter.

A warning doesn't automatically mean something needs changing, and a good score doesn't automatically mean a page is perfect.

The automation simply gives me the information at a much larger scale.

That's the bit I find useful.

Instead of spending my attention running the tests, I can spend that attention understanding the results.

Then Came the Edge Cases

Of course, automating something that normally expects a human sitting in front of it introduces another problem.

Things go wrong.

One of the first things I wanted my auditor to handle properly was failed or unreachable pages.

When you're manually testing a website and a page doesn't load, you immediately know something has gone wrong.

An automated process needs to know what to do next.

I didn't want one broken URL to kill an entire site audit.

If the auditor has already successfully tested dozens of pages and then encounters one that fails, throwing everything away because of that single page would make the automation considerably less useful.

So the function can record that a page failed and continue onto the next one.

That distinction matters.

A failed page is itself useful information.

A failed audit shouldn't necessarily mean a failed auditing process.

Temporary Files Are Still Files

Another interesting part was cleanup.

Running Lighthouse programmatically creates temporary files and intermediate data that are useful while an audit is running but aren't necessarily things I want hanging around afterwards.

This produced one slightly terrifying moment.

During one of my runs I saw output saying files had been removed.

As a developer who has previously experienced the joy of seeing unexpected "deleted" messages appear in a terminal, that wording gets your attention very quickly.

Thankfully, it was doing exactly what it was supposed to do.

It was cleaning up its own temporary files.

But it highlighted another part of automation that I think is easy to overlook.

Cleanup is part of the feature.

Creating temporary files is fine.

Leaving temporary files scattered around after every audit isn't.

So the auditing process doesn't just need to know how to start.

It needs to know how to finish cleanly as well.

The Interesting Part Is Scale

The actual Lighthouse tests haven't fundamentally changed.

I'm still using Lighthouse.

I'm still looking at performance, accessibility, best practices, SEO, and the other information it provides.

What has changed is the scale at which I can use it.

That's something I've started noticing with quite a few of my development tools.

A manual workflow can be perfectly good and still stop being practical as a project grows.

The question isn't always:

"Is there something wrong with this workflow?"

Sometimes the better question is:

"Does this workflow still scale?"

For manually auditing one page, yes.

For repeatedly auditing an entire site, not really.

And that's where automation becomes useful.

What I've Learnt From Building It

One of the biggest things I've learnt from building development utilities like this is that the main feature is usually the easy part.

"Run Lighthouse against a list of URLs" sounds straightforward.

And conceptually, it is.

But a useful tool has to deal with everything around that happy path.

What happens when a page fails?

What happens when a URL can't be reached?

What happens to temporary files?

Should one failure stop everything else?

How do I make the final results useful instead of producing a mountain of raw output?

Those edge cases are what turn a script that works on my machine once into something I can actually rely on.

And I think that's probably my main takeaway from this project.

Automate the Repetition, Keep the Decisions

I don't think every development task needs automation.

Sometimes clicking a button is genuinely easier than building a system to click the button for you.

But once I notice myself doing the same predictable process dozens of times, that's usually a sign that it's worth reconsidering the workflow.

Lighthouse is a good example.

Manual auditing hasn't become bad.

My website simply grew beyond the point where manually running every audit was the best use of my time.

So now PowerShell handles the repetitive part.

Lighthouse handles the auditing.

And I get to focus on the bit that actually needs a developer:

Deciding what to do with the results.

Sometimes automation doesn't need to replace a tool.

It just needs to make an existing tool easier to use at scale.

From Project Feature to Reusable Package – Building My Dynamic Theme Kit

Kristieene Knowles — Tue, 14 Jul 2026 13:06:44 +0000

One of my recent goals has been making my code more reusable instead of solving the same problem in every project.

A good example of that is my Dynamic Theme Kit (DTK).

DTK didn't begin life as a package.

It started as the theming engine inside my One Piece Tracker project.

As that project grew, so did the theme system. It eventually reached the point where I realised I wasn't building a theme engine for one application anymore—I was building something that could be useful everywhere.

Instead of copying pieces of code into future projects, I decided it was time to extract it into its own standalone package.

Step 1 – Extracting it

At first I thought this would mostly be moving files around.

It wasn't.

The real challenge wasn't writing new code—it was separating reusable logic from application-specific logic.

That meant identifying everything that genuinely belonged to the theme engine and leaving behind everything that only existed because One Piece Tracker happened to need it.

After several rounds of refactoring, I ended up with a package whose only responsibility is generating theme variables.

It doesn't try to style an application.

It simply exposes CSS variables that each project can consume however it wants.

That separation of responsibilities immediately made the whole design cleaner.

Step 2 – Making it genuinely reusable

Extracting the code wasn't enough.

The next challenge was proving it wasn't secretly relying on assumptions from the original project.

I wanted integrating DTK to be as lightweight as possible.

Ideally, another project should only need to include the kit, provide a palette configuration, and continue styling itself normally.

That meant improving the documentation, simplifying the configuration, removing unnecessary coupling, and making sure DTK wasn't making decisions that belonged to the application itself.

Step 3 – Libraries expose your assumptions

The biggest surprise came once I started using DTK in other projects.

Every integration uncovered another assumption I'd accidentally baked into the original implementation.

One project still used an older CSS variable.

Another highlighted that gradient backgrounds needed different handling.

Another showed that parts of my documentation only made sense because I already knew how the original project worked.

None of those were bugs.

They were assumptions.

Every time I removed one, DTK became less like "theme code extracted from another project" and more like a toolkit that could genuinely stand on its own.

Those smaller projects became the perfect test environment.

Step 4 – Integrating it into Web Weavers World

Once I was confident DTK was genuinely reusable, I integrated it into my business website, Web Weavers World.

This felt like the real test.

Unlike my smaller experiments, this is the website that represents my work as a developer.

I didn't just want the themes to work—I wanted the integration to feel natural.

Seeing the site switch themes using a completely standalone package was a satisfying moment.

Even better, I realised future themes no longer require changes throughout the application.

Adding another theme is now largely a matter of adding another palette.

That's exactly what I'd hoped to achieve when I first started extracting the code.

Lessons learned

Extracting a feature into a reusable package is much harder than building it for a single application.

The difficult part isn't the code.

It's removing assumptions.

Questions like:

Is this variable actually generic?
Does this behaviour belong in the package or the application?
Am I solving a reusable problem or a project-specific one?

became much more important than writing new functionality.

More importantly, the process has changed how I think about development.

Instead of asking:

"How do I build this feature?"

I increasingly find myself asking:

"Could this become something I can reuse in every future project?"

That small change in mindset has probably been the biggest benefit of building DTK.

Sometimes the best refactor isn't making code shorter.

It's making code useful more than once.

Entering My Automation Era (Without Letting AI Build My Code)

Kristieene Knowles — Thu, 04 Jun 2026 05:59:04 +0000

On 30th June 2025, I started my web development journey. At the time, my focus was simple: learn the fundamentals, build websites, solve problems, and improve with every project. Like most developers starting out, I spent my days learning HTML, CSS, JavaScript, accessibility, responsive design, deployment, debugging, and occasionally breaking things in ways I didn't think were possible.

Fast forward to today, and I've realised I've entered a new phase of development.

Not an "AI builds everything for me" phase.

An automation phase.

When people hear the word automation, they often assume it means handing over your codebase and hoping for the best. For me, it's been the opposite. I still design my websites, write the functionality, make the architectural decisions, and review everything that matters. The websites are still mine. What has changed is that I've started automating the repetitive tasks around development rather than development itself.

Over the past few months, I've been building up a collection of GitHub Actions, repository audits, validation checks, reporting tools, and AI-assisted review workflows. My repositories now contain security scanning, dependency auditing, workflow validation, issue prioritisation reports, documentation updates, repository health checks, and automated quality reports. None of these tools are writing client projects for me. Instead, they're acting as a second set of eyes, constantly reviewing things that would otherwise require manual effort.

AI As A Team Member, Not A Replacement

One of the biggest mindset shifts I've had is moving away from asking:

Can AI build this for me?

and instead asking:

Can automation help me verify this?

As a solo developer, I don't have a dedicated QA engineer, security reviewer, documentation writer, or DevOps team. That's usually just... me.

Automation helps bridge that gap.

A GitHub Action can run checks while I'm asleep. An automated report can highlight issues before they become problems. An AI review can spot patterns I might miss after staring at the same code for hours. None of that removes my responsibility as the developer; it simply gives me more visibility into what's happening across the codebase.

The Review Era

The interesting thing is that most of my automation isn't focused on creating code.

It's focused on reviewing code.

That's where I've found the biggest value.

The more automation I add, the more involved I become in the actual development process. Instead of spending time on repetitive checks, I spend more time making decisions, reviewing results, improving architecture, and focusing on the user experience. Automation hasn't reduced my responsibility as a developer; it's given me better tools to manage it.

That small change in thinking—moving from code generation to code verification—has probably saved me more time than any code-generation tool ever could.

Looking Back

If you had told me on 30th June 2025 that I'd eventually have automated audits, repository health reports, workflow validation, issue prioritisation, monitoring, and AI-assisted review processes running across my projects, I probably wouldn't have believed you.

At the time, I was just trying to make websites work.

Today, I'm building systems that help keep those websites healthy.

And honestly, that's been one of the most rewarding parts of my development journey so far.

The code is still mine.

The decisions are still mine.

The responsibility is still mine.

I've just built myself a really efficient team.

That Moment You See ‘Deleting…’ in Git Bash

Kristieene Knowles — Wed, 04 Mar 2026 20:51:34 +0000

The Fear of Using Git Bash Too Early in Your Dev Journey

When I first started learning development about six months ago, Git Bash felt like stepping into a control room full of buttons I didn’t understand.

I had connected Git to my local VS Code environment and thought:

“Okay, this must be what developers use… I’ll just follow along.”

The problem was that I didn’t actually understand the commands I was running.

One day I ran a command in Git Bash and suddenly my terminal started printing lines that included words like “deleting”.

My brain instantly went into panic mode.

Not deleting in the repo.

Deleting in my actual Windows file system.

Inside my /htdocs/ folder.

At that moment I realised something important about Git:

Git is powerful — but if you don’t understand what a command does, it can be terrifying.

I aborted the command as quickly as I could, but by then the damage had already started.

For a few seconds I genuinely thought I had just lost my entire working project.

Thankfully, I had a backup, so I restored everything and carried on.

But that moment taught me two lessons that stuck with me.

Lesson 1 — Git Isn’t Dangerous, Ignorance Is

Git commands can look intimidating because they operate at a very powerful level of your file system.

When you see words like:

reset
clean
rm
delete

…it feels like you're about to destroy your project.

But Git isn't the enemy.

Running commands without understanding them is.

Once I slowed down and actually learned what commands like checkout, pull, and reset do, Git stopped feeling scary and started feeling like a safety net.

Lesson 2 — Always Backup Your Work

The real hero of that moment was my backup.

If I hadn’t had one, I genuinely could have lost hours (or days) of work.

After that experience, I decided to automate the process.

I created a small PowerShell script that automatically backs up my /htdocs/ folder, so I always have a copy of my working files.

Now backups happen without me even thinking about them.

That one small script removed an enormous amount of stress from my workflow.

Lesson 3 — Fear Is Part of the Learning Curve

Looking back, the fear I felt in that moment was actually part of the learning process.

Every developer eventually reaches a point where they realise:

Tools like Git aren’t just version control — they’re power tools.

And power tools require respect.

Once you understand them, they stop being scary and start being incredibly useful.

Final Advice for New Developers

If you're just starting with Git:

Don’t blindly copy commands from tutorials

Take time to understand what each command does

Always keep backups of your important work

Because one day you will see the word “deleting” fly past in a terminal…

…and your heart will skip a beat.

Trust me on that.

I Built My Own dev.to Feed Page Instead of Embedding a Widget

Kristieene Knowles — Sat, 28 Feb 2026 20:21:11 +0000

There’s an easy way to show your dev.to posts on your website.

You paste in a widget.
You let it render.
You move on.

I almost did that.

But the more I looked at it, the more it felt slightly disconnected from how I build everything else.

So I didn’t embed it.

I built my own feed page instead.

Why I Didn’t Use the Widget

This wasn’t about avoiding convenience.

It was about consistency.

My site is fully hand-built — HTML, CSS, JavaScript, structured layouts, injection layers, theme handling. Everything is intentional.

Dropping in a third-party widget would have worked, but it wouldn’t have felt like part of the system.

It would’ve been something sitting inside it.

And that difference matters more than it sounds.

The Approach

dev.to provides a public RSS feed. That’s data.

So instead of embedding a UI component, I fetched the feed, parsed the XML, and rendered the posts as native components on my site.

No iframe.
No external styling.
No layout overrides.

Just data → structured objects → my own card components.

That means:

The posts match my design system
The spacing, typography, and hover states are consistent
The performance impact is minimal
The page works whether someone is logged into dev.to or not

It feels integrated rather than attached.

What I Like About This Pattern

RSS is simple.

It’s stable.
It’s predictable.
It doesn’t try to control your layout.

That separation — content from presentation — is powerful.

dev.to handles publishing and discovery.
My site handles display and brand.

Both do what they’re good at.

A Small Architectural Win

This isn’t a huge feature.

It’s not complex.

But it reinforces something I’ve been learning while building everything from scratch:

Control over the surface area of your site makes everything cleaner long term.

When you own the presentation layer, you’re not negotiating with someone else’s styles, scripts, or structure.

You’re just working with data.

And I prefer building that way.

If you’re building a personal site and want your blog content there too, consider pulling the feed instead of embedding the widget.

It’s a small change — but it keeps your architecture intentional.

I Built My Own Wordle Engine to Support How I Actually Think

Kristieene Knowles — Sat, 28 Feb 2026 10:30:56 +0000

Why I Built My Own Wordle

Like a lot of developers, I enjoy Wordle.
But after playing for a while, I realised I didn’t just want to play it — I wanted to understand it.

So instead of cloning a template, I built my own Wordle engine from scratch.

Not because the world needed another clone.

But because I wanted:

Full control over the word pool
Seeded daily logic I understood completely
A stats system I could extend cleanly
And a version that reflected how I actually think when solving puzzles

That’s how Web Weavers Wordle started.

Custom Word Pool (Under 1k → Nearly 6k Words)

Originally, my word list was tiny — under 1,000 entries.

It worked, but it felt constrained.

So I rebuilt the dictionary layer entirely.

Instead of a single static list, I moved to:

Separate .txt files per word length
Dynamic loading
A combined VALID_SET for fast validation
Per-length counts for UI stats

The pool is now just under 6,000 words, all curated to match the theme (every answer starts with W).

It’s modular, scalable, and easy to extend — without bloating the main script.

That refactor alone made the project feel like a proper engine instead of a weekend experiment.

Daily Logic (Seeded, Predictable, Controlled)

For the daily mode, I didn’t want randomness.

I implemented seeded selection based on the local date:

function seedFromDate() {
  const d = new Date();
  return d.getFullYear() * 10000 + (d.getMonth() + 1) * 100 + d.getDate();
}

This means:

Everyone gets the same word on the same day
The day flips at local midnight
No server needed
No external API calls

It’s deterministic and self-contained.

Which is exactly how I like my systems.

The UX Gap I Noticed

This is where it got interesting.

When solving Wordle, I don’t like filling unknown spaces with random letters.

Before, if I was thinking through a word like:

W _ S T _

I would temporarily type something like:

W W S T W

Just to fill the row visually.

But that felt wrong.

Those letters weren’t information — they were noise.

So I added a new state.

A manual ? placeholder.

Now I can type:

W ? S T ?

It:

Visually preserves structure
Doesn’t affect validation
Cannot be submitted
Acts as a deliberate “unknown” marker

It sounds tiny.

But it fundamentally changed how the puzzle feels to solve.

It added an intentional “thinking state” between blank and evaluated.

And I haven’t seen other clones do that.

What I Didn’t Build (Yet)

I considered expanding daily mode to every word length.

Technically, it would be easy.

Architecturally? It touches:

Stats storage
Streak logic
UI distribution trees
LocalStorage keys
Share formatting

So I didn’t.

The current version is:

Stable.
Clean.
Focused.

I’d rather refine than expand.

Final Thoughts

This project started as curiosity.

It’s now a modular, seeded, PWA-enabled Wordle engine with:

Nearly 6,000 words
Custom daily logic
Clean stats tracking
Share image generation
And a small UX improvement I genuinely love

Sometimes the best way to understand a system is to rebuild it.

And sometimes rebuilding it lets you improve it in small, meaningful ways.

The live version is here, if you'd like to try it; https://webweaversworld.co.uk/html/main/wordle/index.html

When Regex Meets the DOM (And Suddenly It’s Not Simple Anymore)

Kristieene Knowles — Thu, 26 Feb 2026 10:03:46 +0000

I recently built a custom in-page “Ctrl + F”-style search and highlight feature.

The goal sounded simple:

Support multi-word queries
Prefer full phrase matches
Fall back to individual token matches
Highlight results in the DOM
Skip <code> and <pre> blocks

In my head?

“Easy. Just build a regex.”

Step 1: Build the Regex

If a user searches:

power shell

I generate a pattern like:

power[\s\u00A0]+shell|power|shell

The logic:

Try to match the full phrase first
If that fails, match individual tokens

On paper? Clean.

In isolation? Works.

Step 2: Enter the DOM

This is where things escalated.

Instead of just running string.match(), I had to:

Walk the DOM
Avoid header UI
Avoid <pre>, <code>, <script>, <style>
Avoid breaking syntax highlighting
Replace only text nodes
Preserve structure

That meant using a TreeWalker.

const walker = document.createTreeWalker(root, NodeFilter.SHOW_TEXT, {
  acceptNode(node) {
    const p = node.parentElement;
    if (!p) return NodeFilter.FILTER_REJECT;

    if (p.closest("code, pre, script, style")) {
      return NodeFilter.FILTER_REJECT;
    }

    return NodeFilter.FILTER_ACCEPT;
  },
});

Now we’re not just doing regex.
We’re doing controlled DOM mutation.

Step 3: The Alternation Problem

This is where it got interesting.

Even though the phrase appears first in the alternation:

phrase|token1|token2

The engine still happily matches:

power
shell
PowerShell

Depending on context.

So now the problem isn’t “regex syntax”.

It’s:

Overlapping matches
Execution order
Resetting lastIndex
Avoiding double mutation
Preventing nested <mark> elements

Step 4: Two Passes?

At one point I thought:

Maybe this shouldn’t be one regex.

Maybe the logic should be:

Try phrase match
If none found, then try token match

Which sounds simple…

Until you realise your DOM has already been mutated once.

Now you’re managing state across passes.

The Realisation

I understand JavaScript logic.

I understand regex.

But applying that logic safely across a live DOM tree?

That’s a different tier of problem.

Regex is deterministic.
The DOM is structural and stateful.

And once you start replacing text nodes, everything becomes delicate.

What I Learned

Regex problems are easy in isolation.
DOM mutation problems are easy in isolation.
Combining them multiplies complexity.

Also:

The line between “simple feature” and “mini search engine” is very thin.

Where I Am Now

The search works.

Mostly.

It highlights.
It skips protected blocks.
It respects structure.

But it’s not a browser-level Ctrl + F.
Not yet.

And that’s the interesting part.

I now respect the DOM far more than I did before.

And I never thought I’d say this sentence naturally:

I get the logic of JavaScript.
Making that logic behave predictably inside a living DOM tree is the real challenge.

There’s still refinement to do.
Edge cases to tame.
State to simplify.

But that’s the line between “feature complete” and “actually robust.”

And I’m somewhere in the middle of that line.

I Learned More Building One Testimonial System Than From Months of Tutorials

Kristieene Knowles — Wed, 25 Feb 2026 06:10:40 +0000

When I first got into web development, it was very much the “web” side of things that pulled me in.

HTML. CSS. Making something appear on a screen from nothing.

There’s something powerful about writing a few lines of code and seeing it come alive in a browser. That never really gets old.

But over time, something shifted.

I started caring less about just how things looked… and more about how they worked.

The logic.

The structure.

The “why is this doing that?” moments.

Recently, I built my own testimonial system for my site. On the surface, that sounds simple. Just a form and some displayed text, right?

It wasn’t.

I had to think about:

How the data gets stored
How to structure it properly
Validation
Preventing abuse
Connecting front-end to database
Triggering actions after submission
And making sure it all behaves in production, not just locally

There were moments where I broke it.
Moments where I misunderstood how APIs worked.
Moments where I thought I’d finished… only to realise I hadn’t accounted for edge cases.

But that’s where the learning really happened.

I realised something important:

You don’t become “full-stack” by calling yourself full-stack.

You become it by building things that force you to learn the layers underneath.

What started as “I want a testimonials page” turned into:

Working with databases
Understanding data flow
Thinking about security
Writing logic I didn’t think I could write a few years ago

And honestly? That’s been the most satisfying part.

Not the polished UI.
Not the final version.

The messy middle.

The debugging.
The rewrites.
The moments where something finally clicks.

I’m still learning. A lot.

But every time I build something that stretches me a bit further than last time, I feel like I’m actually becoming the developer I wanted to be when I was younger.

And that’s a good feeling.

Why I Still Build Websites From Scratch in 2026

Kristieene Knowles — Tue, 24 Feb 2026 05:15:08 +0000

In a world of drag-and-drop builders, AI site generators, and one-click themes, choosing to build websites from scratch can feel unnecessary.

But I still do.

I run an independent studio, Web Weavers World, where every site is hand-coded. No templates. No visual builders. No plugin stacks layered on top of each other.

That’s not because modern tools are “bad.” They’re incredibly useful. They solve real problems.

I just value control.

When I build from scratch, I know exactly:

What loads and when
Why a layout behaves the way it does
How performance is impacted
What the accessibility trade-offs are
Which scripts are truly necessary

There’s no mystery layer.

Performance matters to me. Not just Lighthouse scores, but real-world responsiveness. Clean architecture matters. Maintainability matters. Accessibility matters.

And honestly ~ I enjoy it.

There’s something satisfying about understanding every moving part of a system you built. From the CSS structure to the backend logic to the analytics tracking.

It also forces better decisions.

When you don’t have a plugin to solve everything, you think more carefully about whether something needs to exist at all.

That constraint is valuable.

I’m not anti-tool. I use modern workflows, automation, and analytics daily. But I choose intentional complexity over hidden complexity.

That’s why I still build websites from scratch in 2026.

Curious how others approach this ~ are you all-in on frameworks and builders, or do you still enjoy the raw build process too?