Running support for a side project around a day job

By deciding, in advance and in public, when you answer, and then keeping that promise. A support email arriving at 10am on a Tuesday is only a crisis if you have implied you answer at 10am on Tuesdays. Tell people you reply within one working day, or in the evening, or on weekends, and most customers are fine with it, because what they want is to know what to expect. Then answer in two fixed batches a day instead of in the gaps between meetings, write down every question that arrives twice, and read every message as the cheapest product research you will ever get. Support done this way takes a few hours a week for a small side project. Support done reactively takes your whole attention, which is the thing your job already owns.

Why does support feel heavier than it is?

Because it arrives on someone else's schedule, into a day you do not control, and each message carries a small implied urgency. The actual time is usually modest. The cost is the interruption and the low hum of knowing something is waiting. The fix is to convert an open-ended obligation into a bounded one: a window, a batch, a queue. That turns "I am always slightly behind" into "I answer at 7pm", which your brain can put down.

It also helps to say what you are. "Built and run by one person, replies within a day" on the contact page is not an apology. It is accurate, it sets the window, and many customers prefer it to a help center that answers in four days with a ticket number.

What should you promise, and what should you not?

Promise a response time you can keep on your worst week, not your best one. If you can reliably answer every evening, promise one working day and beat it most of the time. If your week has nights that are not yours, promise two days. The number matters less than keeping it; a kept two-day promise builds more trust than a broken same-day one.

Do not promise phone or live chat. Do not promise weekend coverage unless weekends are when you actually work. Do not promise a fix date for a bug in the first reply; promise to look, say when, and then say what you found. And if your side project is for businesses, be explicit that it is not a 24/7 service. Some customers need that and will leave, and it is better they leave before paying than after.

Which support should you automate, and which never?

Automate the questions that arrive more than twice. The pattern for a solo builder is simple: every time you write the same answer a second time, it becomes a page. Over a few months that page becomes a short help section, and the help section answers a large share of incoming mail before it is sent. If your project is vibe coded, this is a good use of the builder you already have: a help page or a small FAQ inside the app is an afternoon, and a "something broke" form that captures what the user was doing is worth more than a generic contact email.

Never automate the first reply to a paying customer with a problem, and never automate anything that sounds like a human but is not. A short, real reply from the person who built the thing is the single thing a side project can do that a larger product cannot, and it is cheap. Keep it.

What do you do about the day job?

Keep the two apart in ways that are visible to both. Do support on your own time and your own devices; the general version of the employment and IP basics is worth reading once if you have not (your contract, your country, and what you built on whose time), but the everyday rule is simpler: your employer's hours are theirs and your evenings are yours, and support should never put that line in doubt. Do not take support calls at your desk, do not use the work laptop, and do not let the support window overlap the hours you are paid for.

The other thing to protect is you. Support plus a job plus building is three jobs, and the one that usually gives is sleep. If support is eating the evening, the answer is not to stay up; it is to narrow what you promise, raise the price so fewer people pay more, or decide the project is done. Pausing a side project is a legitimate outcome and deserves its own honest page; it is not what this one is about, but it belongs in the list.

One builder we interviewed, who is "still working my full time job" and has his app live on both stores, put it plainly: getting the app in front of people while maintaining it "is very time consuming and expensive if you don't have the patience to grow a customer base organically." Asked what he would hand off if he could, he did not say the maintenance: "I would love to hand off the social media marketing or really any promoting of the app." The support load is manageable with a system. It is the everything-else, on top of a job, that is not.

How do you turn support into product information?

Keep a single list, in whatever tool you already have open, of every question and complaint, with a one-word tag: bug, confusion, missing, pricing, praise. Read it once a month. Three "confusion" entries about the same screen are a design task worth more than any new feature. Two "pricing" entries asking if there is a cheaper plan are a signal about who you are attracting, not an instruction to lower the price (see how to price a side project). And "missing" entries are where the next paid feature lives, if it lives anywhere.

This is also where you learn whether the project is a business. Support from paying customers is a cost you can price into the number. Support from free users who will never pay is a cost with no line to charge it to, and after a few months of it, that is useful information about what to offer and to whom. If that sounds familiar, the next step is turning a few of those free users into paying ones, and if you are earlier than that, finding users in the first place is covered in where a side project's first users come from.

What is the minimum setup?

One inbox that is only for the project, a one-line response promise on the contact page, two fixed times a day you look, a saved-replies file that grows one entry at a time, and a monthly half hour to read the tags. That is the whole system, and it fits around a job. It does not make the project succeed; the hard parts of a side project, finding what sells and selling it, stay hard and take weeks to months, and no tool shortens that part, ours included. The four jobs of starting a business are mapped in how to start a business with no experience; support belongs to the fourth one, and its honest job is to keep the customers you worked so hard to find. The gap between a vibe-coded app and a business is walked in you vibe coded an app, here is what is still missing, and the general version is how to turn a side project into a real business.

baget takes the business side of your side project, the admin, the offer, the checkout and the customer follow-up, so your evenings go to the users, not the inbox. One line is enough to start, and it costs nothing to look.