No-code or custom build?

No-code tools have improved fast. Webflow builds visually polished sites. Squarespace handles most small business needs out of the box. Shopify runs commerce without a developer. Notion, Airtable, and similar tools run internal workflows without writing a line of code.

The question isn't whether no-code tools are good — they are. The question is whether they are the right tool for the specific thing you need to build. This is a tool call, not a values debate.

What no-code tools actually are

No-code platforms are pre-built systems with editors layered on top. The platform does the technical work — hosting, SSL, database structure, email delivery, checkout — and you configure it through a visual interface. The tradeoff is that the platform decides what is possible. Everything inside the editor's options: yes. Everything outside: no, or "only with a plugin," or "only with a Zapier connector that runs on a delay and costs extra."

This is a feature for most use cases. A restaurant doesn't need to understand web hosting. A service business doesn't need to know what a database is. The platform handles the infrastructure and the business handles the content.

The constraint only bites when your business has a specific need the platform wasn't designed for.

When no-code wins

No-code is the right choice when:

• The site's job is content + contact. Pages, a contact form, photos, maybe a blog. If these are the only requirements, a custom build costs more to build and more to maintain for no meaningful difference in outcome.
• Budget is under $5,000 or timeline is under two weeks. A no-code tool launches faster, often the same day, and puts the site in the hands of the team immediately. A custom build needs scoping, a developer relationship, and deployment infrastructure before a single page goes live.
• Your team needs to update content without a developer. Editing a Webflow or Squarespace site is designed for non-technical staff. Editing a custom-built site without a CMS requires a developer every time copy changes.
• You're validating that a product or service works. Before investing in a custom build, a no-code version tells you whether the market exists, whether the pricing resonates, and whether the offer converts. Spending $15,000 on a custom build before you have a single customer is a real risk that a no-code MVP removes.

When no-code hits a wall

The situations where no-code platforms stop being the right tool:

• You need server-side business logic. Custom pricing calculations, customer tiering, approval workflows, conditional access to content based on account status — these require code running on a server. No-code platforms can approximate some of this with logic layers, but complex rules become brittle in a visual editor designed for content, not computation.
• You need to own your data. Data in a Webflow or Squarespace site lives in that platform's database. If the platform changes its pricing, acquires a competitor, or shuts down, extracting your data in a clean format is harder than it sounds. Businesses where the customer database is a core asset — healthcare, finance, high-stakes service businesses — often choose custom builds specifically for data ownership.
• You need an integration the platform doesn't support. Connecting to an internal system, a legacy database, or an API that doesn't have a native connector or Zapier integration usually requires server-side code. The workaround is usually a webhook and a background service, at which point you've already built the custom layer.
• Your buying flow doesn't fit the platform's model. Shopify's checkout is designed for physical products with variants and shipping. If you're selling a service with a custom quote process, a subscription with a custom trial period, or a digital product with fulfillment conditions the platform doesn't model — the platform becomes an obstacle rather than an accelerant.

The platform risk most people ignore

No-code platforms change. Pricing restructures. Features that were free become paid. Editors that worked one way get redesigned. The business that built its entire operation in one platform inherits that platform's roadmap decisions.

This isn't an argument against no-code. It's an argument for understanding what you're accepting. When you choose a platform, you're choosing a vendor relationship — one where the vendor can change the terms unilaterally. The question is whether the current cost and capability justify that dependency, not whether the dependency is good or bad in the abstract.

For most small business websites, the answer is yes: the platform's value outweighs the risk. For a business where the website IS the core product — a SaaS, a marketplace, a custom commerce operation — the dependency calculus changes.

The one question that cuts the decision

List what your site or tool needs to do. Then ask: can a no-code platform do every single item on this list, or does any item require code that runs on a server you control?

If the answer is "yes, the platform handles everything" — use the platform. You'll launch faster, spend less, and avoid creating a maintenance dependency on a developer for day-to-day content work.

If the answer is "no, at least one thing requires a server" — that's the inflection point. The next question is whether that one thing is important enough to justify a custom build, or whether you can build around it with a workaround, a Zapier step, or by reconsidering whether that feature is necessary right now.

Most businesses that end up with custom builds tried the no-code tool first and hit a specific wall. That's often the right sequence — validate with no-code, then build custom once you know exactly what the custom logic needs to be.

For businesses that have already hit the wall — where the constraint is a specific business requirement the platform cannot model — that's exactly the work we do. The services page covers what kinds of builds are in scope and what the process looks like. If you have something specific to scope, a brief is the starting point.