The short answer: marketing a side project works when it fits a small, fixed weekly routine rather than a big launch. Spend a few hours a week on one channel where your users already gather, talk to a handful of people directly, and publish one useful thing about the problem you solve. Skip channels that need daily attention or a budget. Consistency over months beats intensity over one weekend.
Side projects have a specific marketing problem. You have the skills to build, a few evenings a week, and a product that deserves users. What you do not have is the time to follow advice written for full-time founders, which usually assumes daily posting, weekly experiments and a budget.
The short answer is to shrink the plan until it fits. A small routine you can keep for six months will get more users than an ambitious plan you abandon after two weeks, and most side projects die from the second pattern rather than from a lack of good ideas.
How do I market a side project with a full-time job?
Side project marketing is the process of getting the right people to find, try and keep using something you build in your spare time, within the hours you can reliably give it. That last part is the constraint everything else has to respect. If a tactic needs you to reply within the hour or post every day, it will collapse the first week work gets busy.
So the useful question is not "what are all the channels" but "what can I do every week, even a bad week, for the next six months". For most people that is somewhere between two and five hours. The routine below is designed for that.
The weekly routine
| Block | Time | What you do | Why it works |
|---|---|---|---|
| Talk to users | 60 min | Message or call five people who use it or have the problem | Tells you what to build and what to say |
| Show up in one community | 60 min | Answer questions where your users ask for help | Builds trust before you ever mention the project |
| Publish one useful thing | 45 min | A short post, a guide or a changelog that teaches something | Compounds in search and gets shared |
| Review | 15 min | Note signups, sources and one thing to change | Keeps you from repeating what is not working |
Three hours is not much, and that is the point. If you have more time, add it to the first block. Conversations with users are the highest-return activity at this stage, and they are also the one people skip because it feels slower than posting.
Put the blocks in your calendar at the same time each week, the way you would a gym session. A routine that depends on finding spare time will lose to work, family and the next interesting bug. A routine with a fixed slot survives a bad week, because you only have to show up, not decide to.
Keep the review block even when the week went badly. Fifteen minutes of noting where signups came from, which conversation was most useful and what you will change next week is what turns the routine from busywork into learning. Without it, you will repeat what is not working for months without noticing.
Pick one channel and stay there
Every channel has a learning curve: the norms, the timing, the kind of post that gets read. Splitting a few hours across five channels means you never get past the curve on any of them. Pick one, and judge it after a month of consistent effort rather than after one post.
How to choose the channel
- Where do your users already ask for help? A subreddit, a Discord, a Slack group, a forum, a corner of X. Go there.
- Can you be useful there without mentioning your project? If the answer is no, it is the wrong place.
- Does it reward consistency over speed? Forums and communities do. Fast-moving feeds that need constant presence do not suit a side project.
Most communities ban or ignore people who arrive only to promote. Spend the first weeks answering questions and being genuinely helpful. When people start recognising your name, mentioning your project where it answers the question becomes welcome rather than spam. Where your first customers come from explains why communities reward members and punish vendors.
Talk to five people a week
This is the habit that separates side projects that grow from the ones that stay at twelve users. Five short conversations a week, with people who use the product or who have the problem it solves. Ask what they were doing when they needed it, what they tried before, and what almost stopped them signing up.
Who to talk to
Start with people who signed up recently, because they remember why. Then people who signed up and stopped, because they know what is wrong. Then people who have the problem but have never heard of you, found through the community you chose. If you are not sure who that last group is, who is my customer is a good place to start.
Write down their exact words. When three people describe the problem the same way, that phrase belongs on your homepage, in your community answers and in the title of your next post.
A short message is enough to start: "Hi, you signed up for my project last week. I build it on my own and I am trying to make it more useful. What were you hoping it would do?" Most people reply, because it is rare to hear from the actual builder. Some replies will be one line. A few will turn into the most useful thirty minutes of your month.
If messaging people feels uncomfortable, that is normal for builders. It gets easier quickly, and the alternative is guessing. For the mechanics of writing to people you do not know, cold email for developers keeps it practical.
Publish things that teach, not things that announce
A post that says "I shipped dark mode" helps nobody who has not already found you. A post that explains how to solve the problem your project solves, with or without your project, keeps bringing people for months, from search and from AI assistants that quote useful pages.
Good side project content is usually small: a guide to doing the task by hand, a comparison of the tools people currently use, a write-up of a mistake you made building it. Write it once, post it where your channel allows, and link to it whenever someone asks the same question. One useful page per week adds up to a library within a year.
Pay attention to the questions that come up in your conversations and your community. Every question you answer twice is a post you should write once. Titles that use the reader's own words, like "how do I export my bank statements to a spreadsheet", match what people type into search and what they ask AI assistants, which is how a small project gets found by strangers.
What to skip
Some tactics consume a side project's limited hours without much return. Skipping them is a decision, not laziness.
- Daily posting on several platforms. It is a full-time job, and most of it reaches people who are not your users.
- Paid ads before you know who converts. With a small budget you learn little and spend all of it.
- A big launch with no users yet. One day of attention, mostly from other makers, then silence. Launch once you have people who can vouch for it.
- Building more features instead of marketing. It feels productive. It is usually avoidance, and i built it but nobody uses it describes where that road ends.
Where this advice does not fit
The routine assumes the project solves a problem real people have, and that you want users more than you want to keep it private. A few cases need something different.
- Projects you are building to learn. If users are not the goal, no marketing routine will feel worth the time, and that is fine.
- Products that only work at scale, like marketplaces or social apps, need a concentrated push in one small group rather than a slow weekly routine.
- Products with a buyer you can name precisely and who pays well. Direct outreach will usually beat community and content, and you should do more of it.
It is also honest to say that some side projects do not find users however well they are marketed. If months of consistent conversations show the problem is not painful enough for people to change what they do, that is useful information, not failure.
When the project starts to work
If people start paying, the routine stops fitting. Conversations turn into sales, the community starts sending more people than you can reply to, and the one channel you chose deserves more volume than three hours allow. That is the point where builders usually either take the project full time or hand the repetitive parts to tools.
Operater was built for that second option: an AI sales agent for builders that takes over finding the right people, writing to each, handling replies and booking conversations, so the hours you have go back into the product. It is in closed beta. Until a project is at that point, the weekly routine above is the better use of your evenings.
Watch for the signals that you have reached that point: people asking for features you would need to charge for, inbound messages you cannot answer within a day, and a channel that keeps producing signups even in weeks you neglect it. Any one of them means the project has outgrown three hours a week, and the next decision is how to give it more time without giving up the job that pays for it.
Key takeaways
- A side project needs a marketing routine sized to the time you actually have, not a launch plan.
- Pick one channel where your users already gather and ignore the rest until it works.
- Talking to five users a week teaches more than any amount of posting.
- Useful content about the problem outlasts promotional posts about the product.
- Momentum on a side project comes from small, repeated actions that survive a busy week.