2
4 Comments

Day 18 Update: Big One. Why I dumped Emergent and rebuilt AgileTask on an independent stack

Stage: solo founder, 1 real user (me), €0 MRR, rebuilding the foundation before chasing growth.

For the last few months, AgileTask.ai was living inside an Emergent wrapper. It was the fastest way to get a working product on the internet. It was also the main reason I couldn't ship anything that actually moved the needle.

This week I ripped it out.

Here's what broke the camel's back, what the new setup looks like, and why I think solo founders in 2026 should seriously consider running their own stack with an AI agent as the second pair of hands.

What wasn't working with Emergent

- Black box hosting. When something broke, I couldn't reach into logs, DNS, queues, or the DB the way a real operator needs to. I was always one abstraction removed from my own product.

- Email deliverability was a ghost. Password reset emails silently failed for days. The reset endpoint was literally returning the temp password in the API response instead of sending an email. I only found it because I tried my own forgot-password flow.

- Analytics was three overlapping tools (Plausible, Humblytics, Crisp) fighting for the same signal, none of them trustworthy.

- I couldn't attach my own domain cleanly. Users landing on an emergent.sh preview URL is not a product. It's a demo.

- Every "small" fix required waiting on a platform. For a solo founder, that's lethal.

This is not a dunk on Emergent, it's a great tool to go from idea to running product in a weekend. But the moment you're serious about customers, email, SEO, and real ops, you need to own the stack.

The new architecture (all independent, all mine)

- Web: Vercel

- API: Railway

- DNS + edge: Cloudflare

- Data: MongoDB Atlas

- Email: Postmark (SPF + DKIM + DMARC aligned)

- Error tracking: Sentry

- Analytics: PostHog — one source of truth, killed Plausible + Humblytics + Crisp

- Source of truth: GitHub, feature branches, PRs into main, Vercel auto-deploy on merge

Nothing exotic. All boring, all proven, all independently swappable.

The part that actually changed the game: AI agent as orchestrator

This is the piece I didn't expect.

I'm running Perplexity Computer (the agent) as my second pair of hands, full-time. Not as an autocomplete, not as a chat window, as an orchestrator that actually operates the business.

In the last 48 hours it has:

- Opened and merged 3 PRs (removing legacy analytics, fixing the password-reset endpoint, hardening observability)

- Run direct mongosh commands against production to clean out a sample dataset that was leaking "fake users" into my metrics

- Managed my Postmark suppression list and verified bounces

- Triaged Sentry issues

- Updated the changelog in the app itself so users can see what shipped

- Wrote today's diary entry and tomorrow's top-3 TO DO as Apple Notes, mirrored to my email, on a daily cron

I write the intent in plain English. It executes across GitHub, Railway, Vercel, MongoDB, Postmark, Sentry, PostHog, Mail, Apple Notes. Every action is logged. If it screws up, I roll back the PR.

Net effect: I'm a solo founder with the shipping cadence of a 3-person team, and zero platform lock-in.

What this means for AgileTask's users

- Password reset actually works now

- Emails come from support@agiletask.ai with proper auth (no more spam folder)

- The product lives on its own domain, owned by me

- The changelog page (`/changelog` in-app) is now updated on every real change, not every few weeks

- The next phase is distribution, not infrastructure. Finally.

What I'd tell another solo founder

1. Ship on a wrapper to validate. Leave the wrapper the day you have a single real user who depends on email, DNS, or data integrity.

2. Pick boring, swappable infrastructure. Vercel + Railway + Cloudflare + Atlas + Postmark + Sentry + PostHog is fine for 99% of us.

3. Hire the agent. Seriously. The leverage of a capable AI orchestrator with access to your actual tools is bigger than any "AI feature" you'll build into your own product this year.

4. Write a runbook. Even if only you and the agent read it.


Next week I'm back to founder-led distribution: build-in-public, warm outreach, and turning promo codes into real conversations. Updates coming.

Big thanks to two people who gave me useful pushback while I was figuring this out: @nick and @koru — this one's for you. Follow-up email incoming.

If you're a solo founder who just moved off a platform wrapper or is thinking about it, I'd genuinely like to hear how you decided. Reply here.

— Giuseppe, building AgileTask.ai

posted toAvatar for product AgileTask.ai
AgileTask.ai
  1. 1

    Quick question — during all of that, did you ever notice parts of the system behaving inconsistently over time even when nothing obvious changed?

    I’ve been seeing that pattern a lot with AI-driven setups.

    Working on something that stabilizes that kind of drift underneath systems — not replacing anything, just keeping behavior consistent.

    Curious if you ran into that at all.

    1. 1

      Honestly no; my comment was about validation and delegation, not anything AI-infra related, so I don't have a useful data point for you here.

      Good luck with what you're building though. If you have a concrete example of the drift pattern you're solving, I'd read it. Right now it's a bit abstract for me to react to.

      1. 1

        Totally fair — that’s on me for keeping it abstract.

        Here’s a simple real-world drift pattern:

        You have a workflow or agent that’s working correctly at first — outputs are aligned, decisions make sense.

        Then over time:

        • small context changes stack up

        • retries / patches get added

        • state gets slightly inconsistent

        Nothing “breaks,” but:

        • outputs get less consistent

        • decisions start contradicting earlier ones

        • edge cases behave differently each run

        So you end up babysitting it or patching it instead of trusting it.

        What I’m building is basically a layer that:

        • detects that deviation from the original “correct state”

        • stabilizes it

        • and brings it back to a known-good behavior automatically

        Not a full agent system — more like a stability layer that sits underneath.

        If that’s not something you’ve run into, totally makes sense why it sounded abstract.

        1. 1

          It works 95% of the time… but that 5% forces you to stop everything and fix it.