Coder Legion - Recent posts tagged build

Static vs Dynamic Websites for SEO

Tue, 08 Sep 2026 15:50:00 +0000

Direct answer: neither static nor dynamic websites are inherently better for SEO. A static model often fits a small, stable site when technical owners can build and deploy changes. A dynamic model often fits frequent publishing, structured records, many editors, or application features. Both can rank when important content and links are accessible, pages return meaningful status codes, URLs remain stable, metadata is correct, and the system is maintained.

This guide chooses a publishing architecture by content change frequency, editorial ownership, scale, integration needs, performance, and operational risk. It does not compare specific frameworks or website builders, teach client-side rendering, or provide a migration runbook. If changing architecture will also change live URLs or templates, use the site migration SEO checklist before launch.

The short decision

Operating condition	Likely fit	Main reason
A small service or brochure site changes a few times per month	Static	Prebuilt pages can keep delivery simple when a technical owner controls publishing
Editors publish frequently without developer help	Dynamic or CMS-backed	Roles, previews, structured fields, scheduling, and revisions reduce editorial friction
Thousands of products, locations, listings, or records share templates	Dynamic or hybrid	Structured data sources can generate and update many pages consistently
Personalized account or application features sit beside public pages	Hybrid	Public pages can be pre-rendered while authenticated functions remain dynamic
The initial response is a nearly empty app shell and important content needs JavaScript	Repair the output	The immediate problem is rendering and discovery, not the architecture label

A hybrid system is normal. A site can generate public pages at build time, refresh selected pages after publication, read content from a headless CMS, and use dynamic endpoints for search, forms, inventory, or accounts. Choose components by job instead of forcing the entire site into one category.

1. Define static and dynamic by when HTML is produced

A static page is prepared before a visitor requests it, then served as an existing file or cached artifact. It can still be generated from templates, Markdown, a database, or an API during a build. It can also contain forms, analytics, interactive components, and JavaScript enhancements. Static does not mean handwritten, unchanging, or free of JavaScript.

A dynamic page is assembled or selected in response to a request, usually from application logic, structured content, a database, or a CMS. It can still return complete server-rendered HTML, use aggressive caching, and load quickly. Dynamic does not mean slow, uncrawlable, or visually complicated.

Client-side rendering is a separate decision. Google describes JavaScript processing as crawling, rendering, and indexing. A browser can receive a minimal shell and build the page later, whether the content originated in a static build or a dynamic service. That extra dependency is what must be tested.

2. Measure the publishing workflow before choosing

Count real changes for a representative month. Include new pages, edits, redirects, media replacements, legal updates, product changes, urgent corrections, and removals. Then record who makes each change, what they need to preview, who approves it, and how quickly it must go live.

Choose static more confidently when changes are limited, a technical owner is available, deployments are reliable, and most pages share a controlled template.
Choose dynamic more confidently when non-technical editors publish often, structured records change independently, multiple roles need permissions, or content must be scheduled.
Choose hybrid more confidently when public acquisition pages need predictable output but parts of the product require live data or personalization.

Do not ask only whether an editor can publish. Ask whether the system prevents missing titles, accidental duplicate URLs, broken internal links, oversized images, invalid canonicals, and stale records. A convenient editor that produces inconsistent pages creates a maintenance cost. A simple static repository that only one unavailable developer understands creates a different maintenance cost.

3. Test the SEO output, not the platform label

Google's current minimum technical requirements are direct: Googlebot must not be blocked, the page must return an HTTP 200 success response, and it must contain indexable content. Meeting those requirements makes a page eligible for indexing but does not guarantee indexing or rankings.

For every representative template, verify the initial response and the rendered result:

the final URL returns the intended status code and does not rely on a soft error page;
the primary content, H1, title, description, canonical, and relevant structured data are correct;
important navigation and contextual links are normal anchors with resolvable href values;
robots rules, authentication, CDN controls, and resource policies do not block necessary content;
mobile and desktop receive the same essential page job and information.

Google can render JavaScript, but its documentation still recommends server-side or pre-rendering because it can improve delivery for users and crawlers, and not every bot runs JavaScript. Use the technical SEO audit workflow to compare the live crawl with Google evidence rather than assuming a successful browser screenshot proves indexability.

4. Compare performance with representative templates

Static delivery can reduce request-time computation and make caching straightforward. That is an operational advantage, not an automatic performance win. A static page can still ship oversized images, unused scripts, third-party tags, layout shifts, and a large client bundle. A dynamic page can return fast, cached HTML with optimized assets.

Test the templates that carry business value: homepage, service, article, category, product, location, and conversion page. Measure the production build on realistic phones and connections. Separate server response, HTML delivery, asset weight, rendering work, and third-party code so the team knows what the architecture actually changes.

Do not choose a platform from a demo homepage or a vendor benchmark. Build one representative page with real navigation, fonts, images, analytics, consent controls, and content. If LCP, CLS, or INP is the actual failure, use the Core Web Vitals diagnosis rather than treating static conversion as the fix.

5. Compare editorial control and content integrity

Dynamic content systems often justify their complexity through editorial safeguards: required fields, validation, reusable entities, role-based access, scheduled publication, previews, revision history, and central media management. Those capabilities matter when publishing errors are more likely than server errors.

Static workflows can provide similar controls through schemas, automated checks, pull-request review, preview deployments, and content builds. They work well when the team is comfortable with that workflow. They fail when every spelling correction requires an outside developer and the resulting queue leaves prices, staff, hours, or service details stale.

Decision rule: choose the least complex system that lets the actual owners publish accurate, accessible pages at the required frequency without bypassing validation.

Run a publishing drill before signing. Ask the intended editor to create a page, change its slug, replace its image, preview mobile output, schedule it, restore an earlier version, and retire it safely. Record where technical help is needed and which changes can break site-wide templates.

6. Compare scale, integrations, and URL stability

Page count alone does not decide architecture. A static generator may handle thousands of pages efficiently, while a poorly designed build may become slow or fragile. A dynamic system may update one record instantly, while a weak template can expose duplicate parameter URLs or inconsistent metadata at scale.

List the data relationships the site must maintain:

products, variants, availability, prices, and categories;
locations, practitioners, services, opening hours, and service areas;
authors, articles, topics, translations, and related content;
accounts, bookings, search, filters, payments, and private records.

For each relationship, decide its source of truth, update frequency, owner, fallback behavior, and public URL. Stable, descriptive URLs and crawlable internal paths matter in either model. Filters and personalization should not create unlimited indexable combinations merely because the system can generate them.

7. Model maintenance, security, and ownership

A small static surface can reduce runtime components and patching obligations, but the full system may still include a generator, package dependencies, build service, CMS, forms, search, analytics, and a CDN. A dynamic platform may centralize updates and access control, but it adds application, database, plugin, cache, and hosting responsibilities.

Question	Static risk to price	Dynamic risk to price
Who can publish an urgent correction?	Developer or deployment dependency	Permissions, plugin, or workflow dependency
What must be patched?	Build dependencies and connected services	Runtime, database, CMS, extensions, and integrations
How is failure recovered?	Previous build and deployment rollback	Application, database, media, and configuration restore
Can the business leave the vendor?	Source, build instructions, and service credentials	Content, media, schema, redirects, users, and database export

Price the operating year, not just the build. Include hosting, licenses, developer availability, editor time, monitoring, backups, security response, dependency updates, testing, and recovery drills. Name the person responsible for each item.

Use a scored proof before committing

Ask each proposed implementation to complete the same proof:

Build one real template. Use production-like content, media, navigation, metadata, and structured data.
Publish through the real owner. Let an editor or developer complete the normal change and approval path.
Inspect the response. Check status, HTML, rendered DOM, canonicals, links, mobile parity, and error behavior.
Measure production delivery. Include caches, third-party scripts, consent tools, and representative network conditions.
Simulate failure. Roll back a bad release, restore content, revoke a user, and recover from an integration outage.
Export the site. Confirm that the business can recover content, media, redirects, structured records, and build instructions.

Score crawlability, publishing effort, performance, accessibility, maintenance, recovery, ownership, and annual cost. Weight the categories before seeing vendor results so a polished editor or a fast demo does not override the business constraints.

Changing architecture is still a migration

Moving from static to dynamic, dynamic to static, or one hybrid model to another can change rendering, templates, internal links, metadata, canonicals, status codes, sitemaps, and URLs even when the design looks similar. Preserve useful URLs unless there is a documented reason to change them. Map necessary moves to direct permanent redirects and compare old and new outputs before and after launch.

Do not combine a platform move, redesign, domain change, URL rewrite, content cleanup, and analytics replacement without a baseline. Each additional change makes losses harder to diagnose. The migration checklist handles the inventory, redirect, launch, and monitoring work; this guide only decides the target architecture.

What not to do

Do not call static automatically fast. Measure assets, scripts, rendering, caching, and real templates.
Do not call dynamic automatically bad for SEO. Complete server-rendered HTML and stable URLs can work well.
Do not select a CMS only for editor convenience. Test the output, validation, roles, recovery, and exit path.
Do not select a static workflow that only one person can operate. Document publishing and recovery ownership.
Do not hide primary content behind interaction or late API calls. Verify the initial and rendered page.
Do not use architecture to excuse stale content. Assign review dates and owners in either system.
Do not change URLs for cosmetic reasons during the move. Preserve accumulated signals and user paths.

Verification checklist

The choice is based on real update frequency, editors, data relationships, and integrations.
Representative pages return correct status codes and complete indexable content.
Important content, links, titles, canonicals, and structured data survive the rendered result.
Mobile output preserves the same essential page job and information.
Performance was measured on production-like templates rather than inferred from the label.
The intended owner successfully completed a publishing and rollback drill.
Maintenance, security, backup, recovery, and annual costs have named owners.
The business can export content, media, redirects, schemas, credentials, and build instructions.
Any architecture change has a separate migration baseline and validation plan.

The best architecture is the one the business can operate reliably while producing accessible, stable, useful pages. Static, dynamic, and hybrid approaches are implementation choices. SEO quality appears in the output and in the team's ability to keep that output correct.

Evidence basis

Google's technical requirements, JavaScript processing, server-side and pre-rendering guidance, mobile parity guidance, and general site organization practices were checked from official documentation on August 10, 2026. The decision tables, publishing drill, operating-cost model, and scored proof are FloxoLab operational frameworks, not Google ranking factors or guarantees.

Need the architecture decision tested against the live site?

FloxoLab can inspect crawlability, rendered output, performance constraints, publishing ownership, and migration risk before a platform commitment.

<a href="https://floxolab.

How Long Does It Take to Build a Custom Website? 2026 Timeline

Mon, 29 Jun 2026 07:45:45 +0000

How Long Does It Take to Build a Custom Website? A 2026 Timeline From the Workshop

⏱️ Project Timeline · Updated June 2026 · 10 min read · by Jacob Campbell

I'm Jacob Campbell, and after delivering custom sites for years I can tell you the honest answer to "how long does a website take?" up front: a focused custom business site is usually ready in about a month, while ecommerce and web apps take longer because there's more to build and test. But here's the part most timelines hide — the single biggest variable isn't the developer's speed, it's how quickly content and decisions arrive from your side. I've had a build sit finished for three weeks waiting on a logo. This guide gives you a realistic 2026 timeline for each project type, a phase-by-phase look at where the days actually go, what slows a build down, and exactly how to launch faster without sacrificing quality.

Key facts

~1 month

Custom business website

4–8 weeks

Custom ecommerce store

8–12+ weeks

SaaS / web application

Day 1

Scope & timeline locked

The headline numbers

A professional custom business website typically takes about one month from kickoff to launch. A custom ecommerce store usually runs four to eight weeks, and a SaaS or web application is eight to twelve weeks or more, depending on feature depth. These ranges assume content and feedback arrive on schedule. The coding itself is rarely the bottleneck — in my projects the build phase is the most predictable part; the wait time lives almost entirely on the client side.

A realistic timeline, phase by phase

A typical custom build moves through five phases. Discovery and scope (a few days) locks exactly what's being built. Design and layout (about a week) produces the templates. Development (one to three weeks) is where the hand-coding happens. Content, SEO, and testing (a few days) covers schema, Core Web Vitals tuning, and cross-device QA. Then deployment and launch. Because the code is written rather than assembled from plugins, the testing phase stays short — there are no theme conflicts or plugin incompatibilities to chase down at the end.

What actually slows a build down

I track the cause of every delay, and the pattern never changes. The top four are: slow content delivery (copy, images, logos), late or shifting decisions, scope that wasn't pinned down at the start, and waiting on third-party access — a domain registrar login, a payment account, a CRM API key. Notice that none of these are coding problems. They're planning problems, and every one of them is avoidable with a clear brief and prepared assets before development begins.

How to launch your website faster

If you want speed, do four things before development starts: lock the scope so there's no mid-build redesign; gather your content and brand assets (final copy, high-res images, logo files, brand colours); name one decision-maker for sign-off so feedback doesn't arrive by committee; and prepare domain and payment access in advance. Clients who do this consistently launch on the early end of every range — and a flat-fee scope removes the change-order back-and-forth that stretches most projects elsewhere.

Why custom code doesn't mean slower delivery

People assume hand-coding takes longer than a template. For a quality result, the opposite is usually true. With a template you spend the project fighting the theme, stripping out bloat you didn't ask for, and patching plugins to behave. Custom code is built to spec the first time, so the effort goes into your requirements rather than undoing someone else's defaults. The result is a lighter, faster, Lighthouse-100 site delivered on a more predictable schedule — which is exactly why I don't treat "fast" and "custom" as a trade-off.

Sources & further reading

Timeline ranges reflect my own delivery windows across business, ecommerce, and SaaS projects as of June 2026.

Related services

Frequently asked questions

How long does it take to build a custom website?

A custom business website is usually delivered in about one month. Ecommerce stores take roughly four to eight weeks and SaaS or web applications take eight to twelve weeks or more, depending on features and how quickly content is provided.

Can a website be built faster than a month?

Yes. Smaller sites with ready content and a locked scope can launch in two to three weeks. The fastest projects are the ones where content, branding, and decisions are prepared before development begins.

What slows down a website project?

The biggest delays are late content, shifting requirements, unclear scope, and waiting on domain or payment access. Coding is rarely the bottleneck — planning and content usually are.

Does a custom site take longer than a template?

Not necessarily. A custom build is coded to spec once, while templates often require removing bloat and patching plugins. A quality custom site is frequently delivered on a more predictable timeline than a heavily customised template.

How can I make my website launch faster?

Lock your scope early, gather content and brand assets up front, assign one decision-maker, and prepare domain and payment access in advance. A clear flat-fee scope removes the back-and-forth that stretches most projects.

Get a clear timeline for your website

Tell us what you need and receive a flat-fee quote with a defined delivery window within 24 hours — no monthly fees, no pressure.

Get my free quote

High-cardinality values for build flags in Rust

Thu, 17 Apr 2025 08:10:37 +0000

While working on my demo on WebAssembly and Kubernetes, I wanted to create three different binaries based on the same code:

Native: compile the Rust code to regular native code as a baseline
Embed: compile to WebAssembly and use the WasmEdge runtime image as the base Docker image
Runtime: compile to WebAssembly, use a base scratch image as my base image, and set the runtime when running the code

The code itself is an HTTP server that offers a single endpoint. For the sake of the demo, I wanted it to return the flavour of the underlying image.

curl localhost:3000/get

{"source": "native", "data": {}}

The idea is to have a single codebase that I can compile to native or WebAssembly. I solved this requirement by using a cfg compile flag.

#[cfg(flavor = "native")]
const FLAVOR: &str = "native";

#[cfg(flavor = "embed")]
const FLAVOR: &str = "embed";

#[cfg(flavor = "runtime")]
const FLAVOR: &str = "runtime";

// Use FLAVOR later in the returned HTTP response

In my case, I can live with three different values. But what if I had to deal with a high cardinality, say, fifteen? It would be quite a bore to define them manually. I searched for a solution and found Build Scripts.

>Some packages need to compile third-party non-Rust code, for example C libraries. Other packages need to link to C libraries which can either be located on the system or possibly need to be built from source. Others still need facilities for functionality such as code generation before building (think parser generators).

>Cargo does not aim to replace other tools that are well-optimized for these tasks, but it does integrate with them with custom build scripts. Placing a file named build.rs in the root of a package will cause Cargo to compile that script and execute it just before building the package.

>-- Build Scripts

Let's try with a simple build.script at the root of the crate:

fn main() {
    println!("Hello from build script!");
}

cargo build

Compiling high-cardinality-cfg-compile v0.1.0 (/Users/nico/projects/private/high-cardinality-cfg-compile)
 Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.08s

There isn't any log–nothing seems to happen. The documentation reveals the reason:

>The output of the script is hidden from the terminal during normal compilation.
>If you would like to see the output directly in your terminal, invoke Cargo as "very verbose" with the -vv flag.

Let's compile again with the verbose flag:

cargo build --vv

The output is what we expect:

...
[high-cardinality-cfg-compile 0.1.0] Hello from build script!
...

Now is the time to do something useful: I'll use the build script to replace the hard-coded constants above. For that, I'll generate a Rust code file that contains the value passed for flavor.

Note the build script runs before compilation. Hence, it doesn't have access to the cfg flags. Instead, I'll pass the value as a Cargo.toml package metadata key value.

[package.metadata]
flavor = "foobar"

For our build script to read the Cargo.toml metadata, we need to add a build dependency:

[build-dependencies]
cargo_metadata = "0.19.1"

The code is straightforward:

fn main() {
    let metadata = MetadataCommand::new()                                         //1
        .exec()
        .expect("Failed to fetch cargo metadata");

    let package = metadata.root_package().expect("No root package found");        //2

    let flavor = package                                                          //3
        .metadata
        .get("flavor")
        .and_then(|f| f.as_str())
        .expect("flavor is not set in Cargo.toml under [package.metadata]");

    let dest_path = Path::new("src").join("flavor.rs");                           //4

    fs::write(&dest_path, format!("pub const FLAVOR: &str = \"{}\";\n", flavor))  //5
        .expect("Failed to write flavor.rs");

    println!("cargo:rerun-if-changed=Cargo.toml");
    println!("cargo:warning=FLAVOR written to {}", dest_path.display());
}

Get the metadata
Get the package where we want to create the new file
Read the flavor value
Reference src/flavor.rs
Write pub const FLAVOR: &str = <flavor>

On the code side, we only need to use the FLAVOR const from the flavor module:

mod flavor;

fn main() {
    println!("Hello from flavor {}", flavor::FLAVOR);
}

Running the program outputs the flavor configured in the Cargo.toml file:

cargo run

Hello from flavor foobar

Conclusion

In this, I've shown how to use high-cardinality build parameters from the package metadata. I could have achieved the same with environment variables, but I wanted to learn about the metadata section of the Cargo.toml file.

The build.rs file is a handy trick for achieving goals that aren't possible with regular Cargo features.

To go further:

Build Scripts

Originally published at A Java Geek on April 13^th, 2025