The website is the most visible part of what we build

You own the site either way, and it's fully portable. Your code, your content, and your data are yours, and nothing is locked inside a platform only TDN can open. So this is a genuine choice, not a lock-in.

Here's the honest recommendation. The easiest way to keep the site performing, hitting its goals, and building value over time is to keep it on a plan with us. On a plan we maintain it, watch the connected pieces, catch things before they break, and help you get more out of what you've built as the business changes.

If you'd rather not be on a plan with us, that's okay. What matters is that someone with the right skills keeps the system maintained, monitored, current, and aligned with your objectives. That can be us, someone on your team, or another contractor you trust. It's a bit like a car: whether you service it yourself, use the dealership, or go to a mechanic you trust, you don't leave it unmaintained and expect it to keep running well.

On the full platform builds specifically, the system has enough connected parts (automations, CRM integrations, form capture, analytics events, sometimes checkout and affiliate tracking) that most clients keep it on a plan so someone stays accountable when something changes. A checkout flow behaves differently after a Stripe update. An automation starts double-firing because a new tag was added to the CRM. None of these are disasters on their own, and all of them are easier to catch when someone is watching the system.

Yes. Fully.

Your GitHub repository is yours. Your content database is yours. Your analytics data is yours. Your site runs on TDN-managed private infrastructure, not inside a SaaS platform. TDN holds no ownership over work product after the build.

If you bring on an internal developer, they can read the code. If you ever leave TDN, you take everything with you. Nothing is locked inside a proprietary system that only TDN can access.

It depends on the tier:

• Micro: 3 to 5 business days
• Creator Starter: 5 to 8 business days
• Creator Growth: 7 to 12 business days
• WP Starter Clone: 10 to 14 business days
• WP Growth: 12 to 16 business days
• Pro Standard: 7 to 12 business days
• Pro Extended: 2 to 3 weeks
• Enterprise Standard: 3 to 5 weeks
• Enterprise Full: 4 to 6 weeks

One thing matters more than the tier: the timeline starts from the date we have your creative assets in hand. Images, video, logos, and any brand direction you want reflected on the site. This is the most common thing that moves a timeline. If your creative arrives three weeks after kickoff, the clock effectively starts then, because we build the layouts first, then place your imagery, then review the design with you together. A site without your real images and video is hard to react to, and we'd rather you see it with your own visuals in place than form an opinion on placeholders.

Copy is more flexible. You don't need finished copy up front. Many clients write theirs directly against the layouts once they can see them. If you'd rather write it first, we'll wait for it before building the pages. Either way works. It's the visual and creative assets we need ahead of time.

The faster timeline on the JS builds (Astro, Next.js) versus WordPress is real: the validated starter repo cuts setup time significantly.

Yes, for clients who are already on WordPress or specifically want it.

TDN offers two WordPress packages: WP Starter Clone ($2,500 to $3,500, 5 to 8 pages) and WP Growth ($3,500 to $5,000, 10 pages plus blog). Both run on TDN's private self-hosted infrastructure, with the same ownership model, the same client control, and the same Cloudflare protection as the JS builds.

If you're starting from scratch and don't have a platform preference, TDN recommends the Astro or Next.js stacks. They build faster, deliver better performance, need less ongoing plugin maintenance, and pair more naturally with the Martech plans. If you're already on WordPress and want to stay there, TDN will build it well.

It depends on where you're taking the business.

If you're planning to grow, to scale, or to use the most current tools (for example, generating pages and content through AI-assisted workflows), moving off WordPress is usually the right call. The same is true if you want to keep extending what the site can do: an events calendar, on-site payments, an affiliate system, quizzes, multiple library collections, a podcast, and so on. On the Next.js and Payload stack, those capabilities compound instead of fighting each other, and the benefit grows the more you build.

If your WordPress installation is reasonably maintained, your team is trained on it, the plugin overhead is manageable, and you're not planning to expand much beyond publishing more pages of the kinds you already have, staying on WordPress is a legitimate choice.

If the goal is a real step up in visual and operational quality, you'll most likely want to replace WordPress. For a full redesign, building fresh on the new infrastructure is often about the same effort as reworking everything inside the existing WordPress site, especially if that site was built in 2025 or earlier, before a lot of today's design-system and global-styling approaches were available.

The honest version of this answer needs a look at your actual setup. On a scoping call, once we understand the business, we'll review the back-end and give you a direct recommendation rather than a default push toward the biggest option.

It means the CMS is structured for the person who actually uses it, rather than for the developer who built it.

For Astro + Keystatic builds: your VA opens a markdown file in a simple interface, edits the content fields, saves, and it's live. No admin panel to learn, no formatting toolbar to decipher. Publishing is a structured editing task.

For Next.js + Payload builds: your VA opens the block builder in the Payload admin, duplicates a pre-built page template, replaces the content blocks, and publishes. The blocks are configured from the design system, so the layout holds together because it's structured rather than assembled by hand.

And it isn't only for a VA. Whoever is hands-on with the site can use it: the founder, a marketing person on the team, or an SEO resource you work with. The point is that content and pages can be updated by a capable team member without calling a developer or waiting on TDN.

Both. Every TDN build includes design, starting from TDN's own Figma component library and customized to your brand tokens.

That library is one of the strongest parts of what we do. It's fast to build from, flexible enough to grow with you, and built to UI and UX best practices. The components are designed with conversion in mind and shaped specifically around what works for expert-led businesses, so you're not starting from a generic template that happens to look nice. The design system is the source of truth, and development implements it directly from that system.

TDN is not a pure development shop that takes a design file and builds to it. The Figma design system, the code pipeline, and the brand-token configuration are all part of every build.

You can, and many founders do, especially at the smaller build tiers where budget is the binding constraint.

The real difference isn't the price of the build. It's how much the build understands about where the business is going.

We work with expert-led businesses specifically, so we build for the stages that come next. That means you're far less likely to reach a point where something has to be rebuilt from scratch and your original investment is lost. You keep growing from what's already there. It's also built to performance and coding best practices from the start, which is the part that ultimately decides whether a site stays fast and stable as it fills up.

The other difference is breadth. The best websites and infrastructure usually need several disciplines working together: design, front-end development, systems and automation, analytics, and performance. That's a lot to find in one freelancer. Across our team, those are separate roles held by people who do them well.

If your main constraint is build budget and you don't have immediate managed-support needs, say so on a scoping call. We'll tell you honestly whether the fit is right at this stage.