Why we rebuilt zynk.com from the ground up

We've spent the last decade getting very good at one hard problem: moving data reliably between systems that were never designed to talk to each other. Sage and Shopify. Sage 200 and a bespoke CRM. Intacct and a marketplace that changes its API every quarter. That work is precise, opinionated, and engineering-led. For too long, our website didn't reflect any of that.

So we rebuilt it. New brand, new architecture, new content model. Here's the thinking, and why we made some deliberate technical choices that we think are worth explaining rather than hiding.

The motivation: the site had drifted from the product

A website is a promise about how a company works. Ours had quietly stopped keeping it. The visual identity had aged, the messaging spoke to a market that had shifted underneath it, and (the part that mattered most to us) the thing was slow and brittle to change. Adding a new connector page meant wrangling a CMS. Publishing a customer story meant fighting a template. The friction was high enough that we simply published less, which is the worst possible outcome for a company whose entire value proposition is removing friction.

The rebrand gave us the excuse to fix the surface. The rebuild fixed the foundations.

The goals

We set out with four clear objectives:

1. Make the brand match the engineering. Confident, technical, modern. Dark surfaces, a single sharp accent, monospaced detailing where it signals credibility. The site should feel like it was built by the people who build the product, because it was.
2. Reduce the cost of publishing to near zero. Every piece of content (integrations, customer stories, articles) should be cheap and fast to ship. If publishing is hard, you publish less, and a thin content footprint is invisible to both search engines and buyers.
3. Treat content as structured data, not blobs of HTML. Our integrations aren't blog posts; they're records with fields. They deserve a schema.
4. Be fast, secure, and boring to operate. No database to patch, no server to harden at 2am, no CMS plugin treadmill.

The big technical decision: static site, markdown content, no database

Here's where we made a choice that some people will raise an eyebrow at, so let's defend it properly.

We moved to a static site built with Astro, with all content authored as markdown in versioned content collections rather than rows in a database behind a CMS. The site is compiled to static HTML at build time and served from the edge.

Why this is more flexible, not less

The instinct is to assume a database gives you flexibility and static files take it away. In practice, for a content-driven marketing and product-information site, the opposite is true.

Content becomes typed, schema-validated data. Each of our three dynamic collections (integrations, customer stories, articles) has a defined schema. An integration must have a name, a category, the systems it connects, supported records, and so on. The build fails if a field is missing or malformed. That's a level of data integrity a freeform CMS almost never enforces. We get the structure of a database with the validation moved left, to author time, where it's cheap to fix.

The content is the source of truth, and it lives in Git. Every change is a commit. Every page has a full history, a diff, an author, and a review step. We can branch the entire website, preview it, and merge it. Rolling back a bad change is git revert, not a database restore. For a team that already lives in pull requests, this collapses the gap between "editing the product" and "editing the site" into a single, familiar workflow.

Querying without a query engine. Because collections are typed data, we can filter, sort, relate, and aggregate them at build time (group integrations by category, surface related customer stories on an integration page, generate a directory) using ordinary code against a typed API. We get relational-style composition without running, scaling, or securing a database.

The flexibility is in the schema, not the storage. When we need a new content type or a new field, we change a schema definition and the tooling follows. There's no migration to run against production data, no admin UI to reconfigure, no risk of a half-applied change. The model bends; the infrastructure doesn't have to.

Why it's faster

There's no runtime work to render a page. No database round-trip, no template rendered per request, no cold-start API. Pages are pre-built HTML served from a CDN, which means time-to-first-byte is effectively a static file lookup. For a global audience evaluating integration software, that speed is a feature buyers feel before they read a word, and it's a ranking signal search engines reward.

Why it's more secure and cheaper to run

The most secure and reliable component is the one that doesn't exist. No database means no database to breach, no credentials to leak, no connection pool to exhaust, no patching cadence to keep up with. The attack surface of a static site is close to nil. Operationally, it's boring in the best way, and boring infrastructure is what lets a small team ship a lot.

Where this approach doesn't fit, and why ours does

To be fair to the database: static generation is the wrong call when content changes per-user, requires real-time writes, or numbers in the millions of frequently-mutating records. A marketing-and-product-information site is the opposite of all three. Our content is authored, not user-generated; it changes on a publishing cadence, not per request; and it's measured in hundreds of records, not millions. This is precisely the workload static generation was built for. Choosing it isn't a compromise; it's matching the architecture to the problem, which is the same discipline we bring to every integration we design.

Built for both audiences

The site speaks to two readers at once. Commercially, it tells a clear story: what we connect, who we do it for, and the outcomes we deliver. Technically, it backs that story up: structured integration data, machine-readable metadata, a clean information architecture, and an llms.txt so the next generation of AI tooling can understand exactly what Zynk does and which systems we connect. That last detail matters more every month, and we'd rather be early than retrofit it later.

The takeaway

The rebrand made us look like the company we actually are. The rebuild made the website behave like the product we actually sell: structured, fast, reliable, and cheap to change. We didn't pick a static, markdown-driven, database-free architecture because it's trendy; we picked it because it's the right tool for content-driven work, and because matching the architecture to the problem is, quite literally, our job.

If you'd like to talk integrations (Sage to ecommerce, CRM, marketplaces, or anything in between), that's the part of the site we're always happy to put to the test.