Tilda vs WordPress vs a custom build: what a small business should choose

Small businesses hear three confident opinions at once. A designer says a constructor can go live by Friday. A friend says serious sites use WordPress. A developer says anything except a custom build will be thrown away later. Each of them may be right for some business. None of them is right for yours until you name the job the site must do over the next year.

The job is not “have a site.” The job is a short list of actions a visitor must complete, and a short list of changes your team must make without opening a project. A person calls. A price changes. One page matches one ad. A staff member edits the catalog on Monday. Two languages stay in sync. A request appears where the team already works. If you cannot name those actions, you are choosing a label, not a platform.

1. A block constructor is enough when the site is mostly pages

Tilda and similar tools are built for pages made from blocks. A landing page. A short services list. A form. A pricing table. A person without developer access can move a block, change a sentence, and publish. That speed is the product. For a studio, a consultant, or a café that mainly needs calls, that can be the correct choice. Refusing a custom build is not a mistake here.

The limit appears when the site must do more than display content. A member area. A price that depends on options the editor does not support. A form that must create a card in the tool your team opens every morning. A nightly task. Two roles, where a manager sees one set of rows and an accountant sees another. You can fake one of these with a paid block and a manual step. You cannot keep faking the second and third without turning the site into a pile of exceptions.

Ask one export question before you commit. If you leave this constructor in a year, can you take your texts, images, and request list in a format another person can open. If the answer is “only by copying each page by hand,” treat the first version as disposable. That can still be fine for testing an offer. It is a bad choice for the only copy of your catalog.

A constructor also ties changes to its own editor. A developer can help inside that editor. They can fix a form, connect a payment block the platform already supports, and remove what makes the page slow. They cannot turn the same project into an application with its own rules and still keep the constructor as the source of truth. If someone promises both, ask which system wins when they disagree.

2. WordPress fits catalogs, posts, and stores with a named owner

WordPress is a sensible choice when the site is pages, articles, a catalog, or a store, and one person is clearly responsible for it. Staff can edit a product. You can add another language. A developer can change a checkout step without rebuilding the whole shop. I have worked on WordPress stores where the useful change was the buying path itself: what the person sees, what gets saved, and what staff can edit the next day. The problem was not the platform name. The problem was that nobody owned updates.

The usual failure is the pile, not WordPress itself. A theme, a page builder, a form plugin, a cache plugin, a slider, and a second form plugin “just for the landing page.” Each one made sense on its own. Together they make one page wait, and a Friday update can take the store down on Saturday. Before you add the next plugin, name the page where people wait and time it. That pass is what to check before a redesign. A slow plugin is not a reason to redraw the brand. A redraw is not a reason to leave WordPress if the catalog still works.

WordPress also needs a place where changes are tested before they reach the live site. “We will edit carefully tonight” is how a store loses checkout. If you do not have a separate environment, read why a live site is the wrong place for a quiet edit before you accept a plugin as the fix. The same rule applies to a constructor and to a custom build. The platform does not remove that need.

Who edits the site is part of the decision. If every comma waits for a developer, you are paying custom-build money for a system that staff were supposed to edit. If everyone edits, including the person who installs plugins from search results, then nobody owns it. Write down the name of the person who may update it, and the name of the person who may not.

3. A custom build costs less when the site is the process

A custom build, often on something like Laravel, pays off when the site is the process, not a brochure in front of the process. Accounts and roles. A request that must become a card without anyone copying fields by hand. A report a manager opens every Monday. A queue, because the click must not wait for a slow outside service. Several companies, or several branches, that must not see each other’s rows. Blocks can sketch the first month of that work. After that, the exceptions become the business, and exceptions cost more than code.

Do not order a custom build because a constructor felt too simple. Order it when you can point to one weekly action the current site cannot do. “We might want a portal later” is not that action. “Every morning someone copies ten requests into a sheet, and two are missing” is.

The cost people miss is the second year. A custom site needs a person who can change it, a copy where a change can be tested, and a short note that explains how a request moves through the system. Without those, you bought a constructor that only one freelancer can open. A cheap build with nowhere to test is still a live edit. It just comes with an invoice.

Custom does not mean “no editor.” Staff should still change prices, hours, and articles without a deploy if those changes are part of the week. The custom part is the rule: who may see a row, what happens after the button, what gets stored. Put the rules in the build. Put the sentences in an editor.

4. Five questions that settle the argument

Write the answers in plain sentences, not in a feature table. If two people on your side disagree, you do not have an answer yet.

• What must a visitor be able to do in the next twelve months. One sentence. If you need a second sentence, you may be buying two projects.
• Who changes text, prices, and hours every week, and can they do it without a developer.
• Where a new request must appear. A mailbox, a notebook, a card. Then send one request and see if thank you on the site matches that place.
• Can you leave with your texts and your list of requests. If not, say so in the decision, on purpose.
• Where a change is tried before the live site. “On the live site, carefully” is not a place.

Teams skip the request path because the homepage already looks finished. Thank you appeared on the site is not the same event as a person seeing the request. Walk that path on the platform you already have before you pay to switch platforms. The short version is why a lead never shows up. If someone still copies the fields into another tool, that copy step is the real specification, and what breaks between a form and a CRM matters more than the theme.

Use the same five answers when you compare quotes. A constructor quote, a WordPress quote, and a custom quote are not three prices for one object. Ask each person which of the five they cover, and which they leave to you. That gap is what you will pay for later, usually in the week you wanted to launch ads.

5. If you already have a site, do not migrate because of a ranking list

A blog post that ranks platforms is not a reason to move. Move when one of the five answers is blocked, and you can name the block in a sentence a colleague understands. “We cannot show the delivery zone on the page.” “Staff cannot change a price without breaking the layout.” “The form sends mail to a person who left.” Those are reasons. “WordPress is old” is not. “Tilda is for amateurs” is not. “Custom feels more expensive, so it must be better” is not.

When the block is real, move the blocked job first. A new catalog, or a new request path, can live on the next platform while the old pages stay online. A big-bang move of every page, every redirect, and every mailbox on the same Friday is how businesses lose a week. Keep the old address working until one test request lands in the new place and a person who was not on the project can change a price.

Take the content with you on purpose. Texts. Real photos you have rights to use. The list of old requests if you still need it. The addresses search engines already know. A fresh design that forgets the old addresses looks like a new company to people who already trusted the old one. Write the address list before anyone starts discussing colors.

When to ask for help

You can answer the five questions in one afternoon if you are honest about the weekly work. Ask for help when you cannot tell whether the limit is the platform or one broken step, when a move would affect payments or accounts, or when quotes disagree and nobody will say which job is out of scope. The useful result is that decision, written down, plus the path a request takes. A new visual style can come later. It should not lead.

Services cover that kind of choice: which limits are real, what to keep, and what must be built because the week already depends on it. Selected work keeps each result next to the operation that produced it, including store work on platforms that were already in place. If you write, send the one-sentence job, the platform you have now, and what happened to one test request. Leave customer names out.