Building Makontent: an AI that runs a small business's Instagram

Ask a café owner whether they should post on Instagram every day and they'll say yes. Ask whether they do and they'll laugh. Their reasons are always the same three: no time, no budget for an agency, and no idea what to post.

For the last eight months I've been building Makontent on my own. It's a SaaS that takes over that job. It comes up with the ideas, writes the copy, designs the images, schedules them and publishes to Instagram. The owner only has to approve.

This is the first article in a series about how I built it. This one covers what the product is, the problem it solves, and how it fits together. The next ones go into the parts that were hard: prompts, scraping, background jobs, billing and the incidents.

The problem with the tools that already exist

There are plenty of tools for social media. Canva helps you design, and Buffer and Hootsuite help you schedule. They all assume you already have the hard part: an idea, the copy and some sense of design. For a hairdresser between two clients, that is exactly the part they don't have.

So I set myself one rule for every feature:

Would a busy café owner with no marketing background understand this and find it useful in 10 seconds?

If not, it gets cut or hidden. A few other rules came from that one:

  • Done for you, not do it yourself. The product proposes and the user approves or tweaks. Nobody starts from a blank page.
  • From sign-up to the first post in under five minutes, with no creative decisions along the way.
  • Success means posting consistently, not using many features.

What it does: three ways to use it

During onboarding, the user picks one of three modes. They share almost everything under the hood, but they solve different versions of the same problem.

1. Planner: for any small business

Onboarding takes four short steps. The user uploads their logo and Makontent picks up the brand colours from it. Then they enter the business name and niche, choose the mode, and give the topic of their first post. A few seconds later they're looking at a finished post.

Onboarding: the logo step with the extracted brand colours

After that, they can plan a whole month at once. They describe the business in a sentence, paste their website URL or upload a PDF (a menu, a price list, a brochure), choose how often to post, and get a list of ideas to review. They can dictate the description instead of typing it. People write a much better description when they can just talk.

Each approved idea becomes a finished piece:

  • an on-brand image for the feed or a story, using their colours, name and contact details,
  • a caption with a hook, body and call to action,
  • hashtags in three groups (niche, medium, broad),
  • a date and time in the schedule.

A generated post next to its caption

2. Product Autopilot: for shops and car dealers

This mode came from talking to used-car dealers. A dealer has 50 to 300 cars on their website, and the stock changes every day. Many of them post 10 to 15 stories a day by hand from their phone, because they know consistent posting sells cars.

In this mode, the dealer only gives Makontent their website URL. Makontent then:

  1. finds the product pages on the site, even without a sitemap,
  2. learns how to read them (name, price, specs, photos),
  3. imports the catalogue and syncs it again every day,
  4. picks the products for each day (new arrivals first, then price drops, then cars that haven't been posted for a while),
  5. builds posts and stories from the real product photos with a branded template, plus a caption that is checked against the product data,
  6. checks again just before publishing that the car is still for sale.

A dealer story with the price badge, and the approval screen on a phone

No AI-generated images are used here, on purpose. A buyer wants to see the actual car, the photos already exist, and they cost nothing.

3. Brand Autopilot: for a single product

The third mode is for a company with one thing to sell, such as a SaaS. Makontent reads the marketing site and turns it into a brief the owner can edit: audience, pain points, features, proof, offer and call to action. From the brief it builds a library of about 24 content angles across eight themes: features, problems, tips, use cases, offers, myths, proof and comparisons.

Every day it picks angles so that no theme dominates the week. It writes the piece, then renders it as a product screenshot in a frame, a bold text design, or a scene generated by AI.

Three brand pieces, one in each design

What all three share

  • Approval or autopilot. By default, every piece waits for the owner to approve it with one tap on their phone. Plans that include auto-publishing let it go out on its own.
  • Publishing that knows Instagram's limits. Instagram limits how many posts an account can publish through its API in 24 hours. The scheduler checks that limit and holds a piece back instead of failing.
  • Simple plans. Each plan has one monthly pool of posts and one of stories, used by both manual creation and the autopilot. Billing runs on Stripe, with cards in reais or dollars, or a yearly payment by Pix (Brazil's instant payment system).
  • Portuguese and English, in both the interface and the content.

How it fits together

The architecture is simple on purpose. I'm one person, and every extra moving part is one more thing to debug at 2 a.m.

Architecture: one Node.js process with the API, a publisher and an autopilot runner, backed by PostgreSQL and S3, calling Claude, OpenAI, customer websites, the Instagram Graph API and Stripe

  • One TypeScript codebase: React and Vite for the frontend, Express for the API, Drizzle ORM on PostgreSQL, and a shared/ folder for rules both sides need, such as plan limits and billing logic.
  • Two background loops in the same process, one that publishes and one that runs the autopilots. There's no queue service. Postgres handles coordination: a unique key for each autopilot and day means each day's run happens only once, and a crashed run picks up where it stopped.
  • AI behind one small interface. Claude Haiku writes the text, and OpenAI's image model makes the images where they're needed. All prompts go through a single function, so switching providers is a config change.
  • One small EC2 server running Docker Compose, with S3 for media. It's cheap and easy to reason about, and I know where it stops being enough.

I'll explain every one of these choices, and what they cost, in the coming articles.

What turned out to be hard

The hard parts weren't the ones I expected:

  • Keeping the AI honest. A wrong price in a dealer's post is a real problem, not a matter of style. The model writes and the code checks: prices, numbers and claims are validated before anything is published.
  • Reading websites I've never seen, cheaply. The LLM learns how to read a site once, and every daily sync after that costs nothing in AI.
  • Background jobs that nobody watches. The autopilot runs while the owner sleeps, so it has to recover from crashes, never post twice, never post a sold car, and pause itself when something keeps failing.
  • Production on a small server. Turning on one feature once froze the whole machine. I'll tell that story in detail.

What I learned about scope

The first version was a carousel generator with a canvas editor. It answered the question "can AI write a good post?". The product people want to pay for answers a different one: "can I stop thinking about Instagram?"

To get there I mostly removed things: extra formats, extra platforms, extra login methods. Then I added two autopilot modes once I understood the customers who needed them. Narrowing the product made the bigger features possible.

Coming up in this series

  1. What I built (this article)
  2. The model writes, the code decides: fact-checking LLM output
  3. Turning on one feature froze my production server
  4. From a website URL to daily Instagram posts
  5. Teaching an LLM to scrape a website once
  6. Onboarding: from sign-up to the first post in five minutes
  7. How I structure prompts for production
  8. Crash-safe daily jobs without a queue

…and more on billing, security, the Instagram API and building solo with an AI pair programmer.

The architecture, the trade-offs and some sanitized code are also in the case-study repo on GitHub.

I'm Daniel Altenhofen, a senior full-stack engineer in Brazil with 16 years of experience, most recently at SAP. I'm open to remote, international roles. Find me on LinkedIn or GitHub.