Building without code: the preparation no tool does for you

Building without code has genuinely arrived, in the sense that the technical work of connecting a number, handling messages and generating replies no longer needs a developer. That part is solved.

What has not changed is that a bot can only say things somebody decided it should say, and follow rules somebody wrote down. That work exists whichever tool you use, no tool does it for you, and it is where projects stall. The businesses that build something useful in a week are the ones that arrived with the decisions already made.

What we'll cover

• What "no code" removed, and what it did not
• The content inventory
• The twenty real messages
• Decisions only you can make
• Building it with CodeWords
• What has to be true in your systems
• The things that are not written down
• Who owns it afterwards
• A realistic first week
• Making it survive
• Limits worth knowing about
• What to prepare first
• Frequently asked questions

What "no code" removed, and what it did not

Removed. Webhook handling, message parsing, retries, duplicate delivery, storage, deployment, integration plumbing, and the model calls. This is real and it used to be most of the effort.

Not removed. Deciding what the thing should do. Assembling the information it needs. Writing what it says. Choosing what it must never do. Deciding who handles what it cannot.

The proportions have inverted. On a developer-built bot a few years ago, the engineering was most of the project. Now the engineering is a small part and the decisions are nearly all of it, which catches people who budgeted for the old shape.

There is no version of this where somebody else makes those decisions. A tool that promised to would be guessing at your business.

The content inventory

The single largest cause of stalled projects is that the information does not exist in a usable form.

Go through, before touching any tool:

Everything you are routinely asked, with the answer written out as you would say it. Hours, location, parking, prices, what to bring, how long things take, what you do and do not do.

The answers that vary, and what they vary by. "It depends on the size" needs the sizes and the amounts.

What is genuinely uncertain, so the bot can say so rather than inventing something.

What must never be said, including anything you are not qualified to say and anything currently in flux.

Write it in the words you would use with a customer. Copy from an internal document and the bot will sound like an internal document.

Businesses discover during this that their own answers disagree depending on who is asked. Resolving that is valuable independently of the bot, and it is the work.

The twenty real messages

Before designing any conversation, collect twenty actual first messages customers have sent you, unedited.

They will look nothing like the tidy flow anybody would design. They will contain typos, several questions at once, two-word openings, voice notes, photographs, and things that are not questions at all.

That set is your specification and your test suite. Design against it and the bot handles real traffic; design against an imagined conversation and it handles the one case nobody sends.

Keep adding to it. Anything the bot handles badly goes in, and the set becomes the thing you re-run after every change.

Decisions only you can make

Six, and a tool will ask you all of them.

What is it for, in one sentence about a business outcome.

Where does it stop. The questions it should not answer, which for most businesses includes anything about price beyond published figures, anything promising availability it cannot check, and anything requiring professional judgement.

Who handles escalations, by name, in and out of hours. This is the question whose answer predicts whether the project works.

What happens when it does not know. The failure message, which will be sent more often than any other.

What it must never do without confirmation. Book, charge, cancel, commit.

How somebody stops it. The opt-out, and what it applies to.

Answer these before building and the build is short. Answer them during the build and the build takes three times as long, because each is a conversation with somebody who is not in the room.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder, working from your content inventory and your twenty real messages rather than an imagined flow.
3. Authorize the connections to your existing systems and your WhatsApp Business Platform account.
4. Describe the exceptions, which is where the six decisions above become concrete.
5. Run your twenty messages through it before anybody outside the business sees it.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

What has to be true in your systems

If the bot is meant to do anything beyond answering questions, something has to be checkable.

Availability has to live somewhere a system can read, not in a paper diary.

Prices have to be somewhere authoritative rather than in several disagreeing places.

Customer records have to be findable by something stable.

Status has to be recorded as it changes, rather than known by whoever did the work.

Where these are not true, that is the first project and it has value on its own. A bot cannot tell somebody their job is ready if nothing records that it is.

Be honest about this early. A great deal of disappointment comes from expecting a messaging layer to compensate for information that does not exist underneath it.

The things that are not written down

Every business runs on rules nobody has ever stated, and a bot will break all of them in its first week.

The customer who gets treated differently. The service you technically offer but would rather not. The time of day when something is not possible. The question that always means something is wrong. The phrase that means somebody is about to complain.

Get these out of people's heads by asking what the bot must never do, and what they would never say to a customer. Ten minutes with whoever answers the phone produces a list no amount of documentation review would.

Expect to keep adding for months, because these surface only when something violates one.

Who owns it afterwards

Decide before launch, because a bot with no owner degrades quietly.

Somebody has to read a sample of conversations weekly, update the content when prices or services change, notice when the escalation queue grows, and handle the account health. It is not a large job and it is not nobody's job.

Without an owner, the failure is not dramatic. The bot keeps running and slowly becomes wrong, and the first sign is a customer quoting a price you stopped charging last year.

A realistic first week

Day one, the content inventory and the twenty messages. No tool.

Day two, the six decisions, with whoever needs to agree them.

Day three, build the narrow version: the most common questions, the failure message, the escalation.

Day four, test with people who are not you, using the twenty messages and anything awkward they invent.

Day five, twenty willing customers.

Then a fortnight of reading everything and fixing what actually broke, which is the part people skip and the part that decides whether it works.

Making it survive

Keep the content inventory as the source, with an owner and a date.

Grow the message set from live conversations.

Re-run everything after any change, not just the case you fixed.

Name an owner with a weekly reading habit.

Add to the unwritten rules list as they surface.

Limits worth knowing about

No tool decides what your bot should do, and that is most of the work.

Missing information cannot be generated. A business without written answers has to write them.

Systems that cannot be read cannot be reported on, whatever the messaging layer does.

Platform rules still apply, including what a number may be used for and how proactive contact works.

The first version will be wrong in ways nobody predicts, which is why the fortnight afterwards is part of the project.

What to prepare first

The content inventory, written in customer-facing language, with an honest note against anything that varies or is uncertain. It is a day's work, no tool can do it, and every project that stalls stalls here.

Two habits make the difference. Collect twenty real first messages before designing anything, because they look nothing like the conversation anybody would design and they are your actual specification. And settle who answers escalations, by name, before you build, since that single answer predicts whether the finished thing survives its first busy week.

Frequently asked questions

What does building without code actually remove?

The engineering: webhooks, parsing, retries, storage, deployment, integrations and model calls. What remains is deciding what it should do, assembling the information and writing what it says.

Why do no-code bot projects stall?

Because the information does not exist in usable form. A bot can only say what somebody decided it should say, and most businesses have never written their answers down in one place.

What is a content inventory?

Every question you are routinely asked with the answer written as you would say it, plus what varies and by what, what is genuinely uncertain, and what must never be said.

Why collect twenty real messages?

Because real openings contain typos, several questions at once, two-word messages and media, and look nothing like a designed flow. They are both your specification and your test set.

What decisions have to be made before building?

What it is for, where it stops, who handles escalations by name, what happens when it does not know, what it must never do without confirmation, and how somebody opts out.

What needs to be true in my systems?

Availability, prices, customer records and job status all need to live somewhere readable. Where they do not, that is the first project, and it has value on its own.

How do I capture rules nobody has written down?

Ask whoever answers the phone what the bot must never do and what they would never say to a customer. Ten minutes produces a list no documentation review would.

Who should own the bot after launch?

A named person who reads a sample weekly, updates content when things change, and watches the escalation queue and account health. Without one it becomes wrong quietly.

How long does a first version take?

About a week if the preparation is done: a day of content, a day of decisions, a day building, a day testing, a day with twenty willing customers. Then a fortnight of fixing what actually broke.

Will the first version be right?

No, and planning for that is the difference between a project that works and one that is abandoned. Real customers surface things nobody predicts.

Does no-code mean a non-technical person can do all of it?

The building, yes. The preparation needs somebody who knows the business well enough to settle what it should say and where it stops, which is usually a different person from whoever assembles it.

Related reading

• Where no-code stops on this channel
• Testing it before customers do
• The smallest version worth launching