DEV Community: Dean Burt

Six habits that cut no-shows in an appointment business

Dean Burt — Tue, 13 Oct 2026 19:03:45 +0000

An empty appointment slot is the most expensive kind of lost time in a small service business. Nobody turns up, you can't fill the gap at short notice, and you still paid for the chair, the van or the hour. Most no-shows are not rude people. They forgot, something came up, or it was too awkward to cancel.

Here are six habits that cut no-shows without making customers feel policed.

1. Confirm straight away, remind at the right time

Send a confirmation the moment someone books, with the date, time, address and what to bring. Then send one reminder the day before, and a short one a few hours ahead. Two well-timed messages work better than five.

2. Make cancelling easy

It sounds backwards, but if cancelling is awkward, people just don't turn up. Tell customers exactly how to cancel or move an appointment, such as replying to the reminder, and thank them when they do. A cancelled slot you know about can often be refilled. A no-show cannot.

3. Have a clear, fair cancellation policy

Write down how much notice you need and what happens if someone doesn't give it. Say it when they book and again in the confirmation, in plain words. A policy people have seen in advance feels fair. One that appears after a missed appointment feels like a penalty.

4. Use deposits where they make sense

A small deposit is a common way to reduce no-shows, because people turn up for things they have paid for. It tends to suit longer or higher-value appointments and busy times. Keep it modest, explain what it covers, and say whether it is refundable.

5. Rebook before they leave

Ask for the next appointment at the end of the current one, while you are both there. People who leave with a date in their phone are more likely to come back, and it fills your diary further ahead.

6. Keep a short waiting list

Keep a list of people who would take a cancelled slot at short notice. A quick message can turn a gap into a booking, which also makes late cancellations less costly.

Track the number

Count how many appointments you book and how many are missed each month. Even a rough no-show rate shows whether a change is working. If it drops after you add reminders or a deposit, keep doing it. If not, try the next habit.

Why a weekly check-in beats a static workout plan

Dean Burt — Tue, 13 Oct 2026 19:02:14 +0000

Most workout plans fail for a simple reason: they are written once and never change. Life gets in the way, a week goes badly, an exercise doesn't suit you, and the plan carries on as if nothing happened. People don't fail the plan. The plan fails to adjust to them.

A weekly check-in fixes a lot of that.

What a check-in changes

A check-in is a short, regular moment where the plan gets updated using what actually happened:

What you did. Which sessions you completed, and which you missed.
How it felt. Whether the weights and volume were too easy, about right, or too much.
What got in the way. Time, energy, an injury, travel, a busy week at work.

With that, next week's plan can be built around the real week you just had instead of the one you planned. Small adjustments, made every week, beat a perfect plan that never changes.

The same idea for meals

Nutrition plans have the same problem. A fixed meal plan breaks the first time a food you don't like or a late shift turns up. Seven days is a practical planning window: short enough to adjust, long enough to shop and prep for.

How to do it yourself

Pick one day a week for a ten-minute review. Write down what you completed, rate how hard it felt, and note what got in the way. Then change next week's sessions and meals to match. A trainer does this naturally in conversation, and a simple notes page works if you don't have one.

This is general information about how people tend to train, not medical advice. If you have an injury or a health condition, speak to a professional first.

How to build a convincing demo in 24 hours

Dean Burt — Tue, 13 Oct 2026 18:56:34 +0000

Whether it's a take-home test, a hackathon, a paid trial or a quick prototype for a client, there is a skill in building something convincing against a deadline. The people who do it well aren't always the fastest coders. They are the ones who decide early what matters and protect it.

Here are the habits that make the biggest difference when you have about a day.

1. Read the brief twice, then pick the slice

You won't build everything, so decide what to build before you write code. Find the one flow that shows the idea works. If the goal is "people can book and pay a deposit", the slice is the booking form and its confirmation, not the whole system.

2. Get something working end to end, early

A rough version that runs from start to finish beats a polished half. Wire the core flow together in the first few hours, even if it's ugly. After that, every hour improves something that already works.

3. Cut scope on purpose

Write a short list of what you are leaving out, and why. Cutting deliberately looks like judgement. Running out of time looks like a mistake.

4. Record a short demo

People will often see your work for a couple of minutes. A one- to two-minute screen recording that shows the flow working, in the order a person would use it, makes it easy to understand quickly. Say what it does and what you chose to leave out.

5. Write the README and the assumptions

State how to run it, what you assumed where the brief was unclear, and what is mocked. Two minutes of notes saves the reader a lot of guessing and shows you think about the person using it.

6. Say what comes next

Finish with a short list of the next steps and rough effort for each. It shows you can see past the demo to the real project.

Time-boxing the day

A rough split that works: an hour on understanding and scoping, most of the time on the core build, an hour for fixes and polish, and the last hour for the demo and the notes. Protect that last hour. It is the part people actually see.

The 6 things I check on a local business website

Dean Burt — Tue, 13 Oct 2026 18:51:34 +0000

Most small business websites lose enquiries for boring reasons: a slow page, a missing phone number above the fold, a contact form that is hard to find, no reviews or trust signals. None of these needs a redesign. They need someone to look.

Here are the six areas I check first on a local business site, and what to look for in each.

1. Search visibility

Can Google tell what the page is about? Check that each page has a clear title and description, one main heading, and that the page can be indexed at all. A surprising number of sites are set to "noindex" by accident after a redesign.

2. Speed

Slow pages lose people before they read a word. Look at image sizes first, since oversized photos are the most common cause, then at how many scripts the page loads.

3. Accessibility

Check colour contrast, alt text on images, form labels and whether the site works with a keyboard. These help real visitors and tend to overlap with good SEO.

4. Local SEO

For a local business, check that the name, address and phone number are consistent, easy to find, and match your Google Business Profile. Add the town or area to the places people actually read, such as headings and service pages.

5. Trust

Visitors decide quickly whether to believe you. Reviews, real photos, clear pricing or "from" prices, and a visible contact route all help. A site with none of them can feel abandoned even when the business is busy.

6. Conversion

Ask what you want a visitor to do and how many clicks it takes. A call button, a short enquiry form and a clear next step on every page usually matter more than any amount of extra content.

Make it routine

You can check all six by hand in an afternoon. Write the results down, fix the three biggest problems first, and run the same checks again every few months. Small fixes made regularly beat a big rebuild.

How to test a developer before you hire them

Dean Burt — Tue, 13 Oct 2026 18:28:46 +0000

Hiring a developer from a proposal is hard. Pitches, portfolios and quotes all describe what someone says they can do. None of them show how that person would handle your actual project. A small, well-defined trial task gets you much closer to the truth.

1. Choose a task that's small but real

Pick one slice of your actual project that takes a day or less. It should test the things that matter, such as how they structure the work, handle unclear requirements and communicate, not just whether they can follow instructions. A generic coding puzzle tells you less than a piece of your real problem.

2. Write a brief that someone else could follow

State the outcome you want, not the technology. "Visitors can book a session and pay a deposit" is clearer than "build a booking system". Include a budget, a deadline, and any assets the developer needs (copy, logos, example data). A good brief makes the results easy to judge.

3. Use the same task for every candidate

If you try more than one person, give each the same brief, assets and time limit. Then any differences come from the work, not the instructions. Keep the number small, because every extra candidate costs you review time.

4. Pay for the trial

Asking someone to do real work for free is unfair, and the best developers will decline. Agree a fair fee for the trial up front, and agree who owns the result. Paying also makes it easier to be honest about what you did and didn't like.

5. Decide how you will judge it before you start

Write down your criteria first. Useful ones are: does it work, is it clear how it works, did they ask sensible questions, did they say what they left out, and how do they price the full project. Scoring each candidate against the same list keeps the decision fair.

6. Agree the terms in writing

Put the scope, price, payment dates, cancellation rules and what happens if you disagree into a short written agreement before work starts. It protects both sides, and it is cheaper than a dispute.

What to watch for

Be wary of anyone who won't do a paid trial at all, who ignores the brief, or who delivers something polished that doesn't run. A rough version that works and an honest list of what's missing is usually a better sign.

The 4 things I check before launching an AI-built app

Dean Burt — Tue, 13 Oct 2026 18:21:50 +0000

AI coding tools get you to a working app fast. They are less good at the unglamorous parts that decide whether it is safe to put in front of real users. Before I launch anything built with Cursor, Lovable, Claude or ChatGPT, I check the same four things.

1. Exposed keys and secrets

API keys have a habit of ending up in the repo: pasted into a config file to "just get it working", committed, and forgotten. Search the whole repo, including old commits, for anything that looks like a key, token or connection string. If a secret has ever been committed, treat it as leaked and rotate it. Deleting the line is not enough, because it stays in the history.

2. Open databases

A database that works in development is often wide open: no row-level rules, public read access, or a default admin account. Check who can read and write each table or collection when you are not logged in at all. If the answer is "anyone", fix it before launch.

3. Missing auth checks

It is easy for the page to hide a button while the API behind it still answers anyone. For every endpoint that changes or returns user data, confirm the server checks who is asking, and that they are allowed to see that record, not just that they are logged in.

4. Payment bugs

Check that prices and amounts are decided on the server, not trusted from the browser. Confirm that a payment is only treated as successful when your payment provider's webhook says so, and that a failed or repeated webhook cannot give someone free access or charge them twice.

Make it a habit

Do this by hand once so you know what you are looking for, then make it routine. Keep secrets in environment variables, never in the repo. Add a secret scanner to your CI so a leaked key fails the build. Review auth and payment code on every change, not just before launch. A short checklist you run every time beats a thorough audit you do once.