Support as a Solo Maker: Helping Without Burning Out

The first message arrives and it feels wonderful. Someone is using your project and they have written to you. The tenth is nice too. The fiftieth arrives at midnight, from a stranger who is cross about something you never promised, and you wonder why you ever put the thing online.

Support is the part of making that nobody shows in the glossy launch stories. It is also where reputations are built. A kind, clear, timely reply can turn a frustrated visitor into an advocate. A solo maker can do it well, without burning out, with a few simple systems. This guide describes them.

Decide what you offer

Before the messages pile up, decide what you will do.

Ask yourself:

• What kinds of messages will I answer? Bug reports, how-to questions, feature requests, business enquiries?
• How quickly? Within a day? A week?
• When? Evenings? A fixed slot twice a week?
• Through which channel? Email, an issue tracker, a form?
• For whom? Everyone, or paying customers first?

Then say it, publicly and briefly. "I run this alone in my spare time. I reply to messages within a week, usually on Tuesday and Thursday evenings. For bugs, please use the issue tracker."

Stating the pattern is not rude. It is kind, because people then know what to expect and stop worrying.

Reduce the need for support

The best support is the message you never receive. A bit of upfront effort cuts volume.

A clear first run. Most questions come from the first ten minutes. Make them smooth: simple set-up, a visible next step, sensible defaults.

Good error messages. An error that says what happened and what to do prevents a message. "Could not read the file. Check that it is a plain text list, one item per line" is better than "Error 42".

A README or help page with getting-started steps, a short FAQ and known limits.

A changelog so people can see what has changed.

Examples. Show a typical use.

Honest limits. If something is not supported, say so up front.

A search of past questions. Link to resolved issues.

Every time you answer the same question three times, write the answer into the FAQ or the interface.

Build a calm routine

Replying whenever a notification buzzes is a recipe for exhaustion.

• Choose fixed slots. Twenty to forty minutes, a few times a week.
• Turn off notifications outside them.
• Batch. Handle everything in one session.
• Triage first. Skim all messages, sort them, then reply.
• Stop when the time is up. Leave the rest for next time, and trust your stated reply window.

Time management guidance, at its root, says: know your time, choose what matters and protect it. Support deserves a slot, not the whole day.

Triage into four piles

When you open your messages, sort them.

Bugs. Something is broken. Record it, reproduce if you can, fix or schedule.

Questions. Someone does not know how to do something. Answer, then consider whether the docs need a fix.

Ideas. Suggestions for features. Thank, record and move on. Some will go on your later list.

Not now or not for me. Requests outside your scope. Say so kindly.

A simple board, physical or digital, with four columns is enough. Moving a card from one column to another is satisfying and shows progress.

Write replies that help

A good reply is short, kind and useful.

1. Thank them. "Thanks for getting in touch."
2. Show you understood. Restate the problem in a line.
3. Answer or ask. Give the solution or ask for the specific detail you need.
4. Say what happens next. "I will fix this in the next release."
5. Sign off warmly.

Example: "Thanks for the report. If I understand correctly, the export fails when the list has more than a few hundred lines. I can reproduce that, and I have noted it for the next release. In the meantime, splitting the list in two works. I will let you know when it is fixed."

Keep a short collection of templates for common replies, and adapt each one so it reads like a person.

Ask for what you need

For bug reports, a short list of questions saves back-and-forth. What were you doing? What did you expect? What happened instead? What device or version? Any error text? An issue template can ask these automatically.

Say no gracefully

You cannot build everything. A kind no sounds like: "Thank you, that is a thoughtful idea. I am keeping the project small, so I do not plan to add it. If it helps, here is another tool that does that." Most people accept a clear, reasoned no.

Handle difficult messages

Sooner or later, someone will be rude, demanding or abusive.

• Pause before replying. Your first draft will be wrong.
• Read for the real problem under the tone. Sometimes anger hides a legitimate bug.
• Reply once, politely, addressing the substance and ignoring the tone.
• Set limits. "I am happy to help with the problem, but I will not continue if the messages stay abusive."
• You can stop. You are not obliged to respond to abuse.
• Ask a friend to read a difficult message and tell you what it says.
• Keep records of serious threats or harassment, and report them where appropriate.

Your wellbeing matters more than any single user.

Be careful with other people's data

Support messages often contain personal information, sometimes sensitive. Treat it with care.

• Ask only for what you need.
• Never ask for passwords.
• Remove personal details when you copy a message into your notes or an issue tracker.
• Store messages securely, with a strong password and two-step sign-in.
• Delete what you no longer need.
• Do not share one person's details with another.

The Information Commissioner's Office publishes guidance for small organisations on handling personal data, and it applies to your inbox as much as to a database.

Accessibility of your help

Support should be reachable by everyone. Offer more than one way to contact you if you can, such as email as well as a form. Make sure your help pages use real text, clear headings and descriptions for images, and that forms have clear labels and work with a keyboard. The accessibility guidelines for the web offer a framework that applies to help pages too.

Use tools lightly

You do not need a large system.

• A shared inbox or label for support messages.
• A notes file for answers you reuse.
• An issue tracker for bugs and requests.
• A status page or note for incidents.

When volume grows or others help, consider a dedicated tool. Until then, simplicity beats features.

Ask for help

If the project grows, you do not have to carry support alone.

• Invite users to help each other, in a forum or discussion space with light moderation.
• Recruit a volunteer or co-maintainer you trust.
• Hire help if income allows.
• Document your process so someone else can follow it.

Delegating support means giving up some control. It also means you survive.

Learn from support

Every message is data.

• Repeated questions show where the product or docs are unclear.
• Bug clusters show where quality is weak.
• Ideas show where users want to go.
• Thanks show what to protect.

Once a month, read your recent messages as a set and write three lines: what confused people, what broke, what to change.

Know when to pause

If the load is too much, say so.

• Post a note: "Support is slower than usual this month."
• Close the tracker to new requests for a while.
• Hand over or retire the project responsibly, if it comes to that.

Honest communication about limits earns more respect than silent overwhelm.

A support policy in five sentences

1. I maintain this alone in my spare time.
2. I reply to messages within a week, usually on set evenings.
3. Bug reports go in the tracker, with the details asked for.
4. I may not be able to add every feature requested.
5. Abusive messages will not be answered.

Put it on your help page. It will save you a great deal of worry.

Common mistakes

• No stated expectations.
• Answering at all hours.
• Answering every question individually, instead of improving the docs.
• Taking rudeness personally.
• Over-promising.
• Keeping personal data longer than needed.
• Doing it all alone, forever.

On this site

The contact page shows a simple route to reach a person, the submit page starts your listing, whose description can carry a clear support note and the privacy page explains how personal data is handled here. The launches page shows how other makers present theirs, and the blog has more guides for makers.

A story of one good reply

A user wrote to a small maker, annoyed that an export had silently dropped her last three rows. The maker replied the same evening. He thanked her, said he could reproduce it, apologised for the lost data, gave her a workaround that recovered the rows and promised a fix in the next release. Two days later he sent a one-line note: "Fixed in the new version, thank you for the report."

The user posted about it in a forum, not the bug but the reply. Three people tried the project as a result. The whole exchange took the maker perhaps twenty minutes, and it was worth more than any advert. Kindness at the right moment is the cheapest marketing there is, and it is available to every solo maker.

When support teaches you to say no to yourself

Support also shows you what you should stop doing. If you are replying at midnight, you need a firmer schedule. If you are answering the same question weekly, you need a better FAQ. If you are writing long replies to people who never write back, you need shorter templates. Treat each pattern as a prompt to change a rule, and your support routine will get lighter with time rather than heavier.

The short version

State what support you offer and when, reduce questions with clear first runs, error messages and docs, answer in fixed slots, triage into bugs, questions, ideas and not-now, write kind and specific replies, say no gracefully, protect people's data and your own wellbeing, learn from patterns and ask for help when you need it. Calm, clear support is part of the craft.