How I Built DevPostGen

The core problem (not the fancy one)#

The problem was never “AI writing posts”. The real problem was:

1. Developers don’t track their work properly
2. Even if they do, converting it into content is annoying
3. By the time you sit to write, the context is gone

So the goal became very clear: Capture work automatically, while context is fresh, and turn it into usable content with minimal effort.

Breaking the project into three systems#

Very early, I realized one thing: If I try to build this as a single app, it will collapse under its own complexity.

So I split DevPostGen into three independent but connected systems:

• Backend – the brain
• Frontend – the control center
• Extension – the friction killer

This decision alone removed half the mental load.

Backend: where most of the real pain was#

The backend looks boring on paper: Node, Express, MongoDB, OAuth, AI. But this is where most hurdles lived.

Hurdle #1: GitHub data is noisy

GitHub activity is not “clean progress”. Commits can be tiny, messy, reverted, or experimental. Feeding raw commit messages to an AI gave garbage output.

So I had to:

• Fetch diffs, not just messages
• Normalize changes
• Add context before sending anything to Gemini

Lesson learned: AI quality is directly proportional to input quality.

Hurdle #2: OAuth is never as simple as it looks

GitHub OAuth sounds easy until sessions randomly expire or redirects break in local vs production. Passport.js helped, but I still had to deeply understand session lifecycles and secure token storage.

This part wasn’t “hard”, just annoyingly fragile.

Hurdle #3: AI output consistency

AI doesn’t fail loudly. It fails subtly. Sometimes the tone was wrong, or the output felt like marketing nonsense.

I had to:

• Add tone constraints (Hype, Technical, Casual)
• Force structure
• Reject outputs that didn’t meet minimum quality

Treating Gemini like a deterministic API was a mistake. Once I treated it like an unreliable collaborator, things improved.

Frontend: deceptively hard#

The frontend looks clean now. It was not clean while building. The challenge wasn’t React — it was flow.

The hardest question was: “What does the developer do first when they open this?”

I iterated on dashboard layout and activity grouping multiple times. My biggest hurdle was adding features before locking the flow. That always backfired. Once I froze the flow, UI decisions became obvious.

Dark mode was not just aesthetics

I built DevPostGen “dark-mode first” intentionally.

• Developers spend hours here
• Bright UIs are exhausting
• Contrast matters more than color

Bad UI doesn’t feel bad immediately. It feels bad after 30 minutes.

The Chrome Extension: small surface, big headaches#

On paper, the extension is tiny. In reality, it was the most annoying part.

Hurdle #1: Extension state is weird

Chrome extensions reload unexpectedly and kill background scripts. So I had to persist drafts properly and sync state intelligently. You can’t treat an extension like a normal React app.

Hurdle #2: UX in a tiny box

The popup is small. Every pixel matters. This forced ruthless decisions: fewer buttons, clear defaults, no unnecessary configuration.

Ironically, this made the product better. Constraints sharpen decisions.

The biggest mistake I made#

Trying to polish too early.

I spent time on animations and micro-interactions before the core loop was bulletproof. Every time I did that, I paid for it later.

Now my rule is simple: Core loop first. Polish last.

What this project really taught me#

DevPostGen taught me that:

1. Products are systems, not features
2. AI doesn’t replace thinking — it amplifies it
3. UX problems are usually clarity problems
4. Splitting responsibility early prevents rewrites

Final thoughts#

DevPostGen isn’t impressive because of AI, OAuth, or React 19. It’s interesting because it solves a real developer problem: turning invisible effort into visible progress.

If you’re building something similar, here’s your takeaway: Don’t start with features. Start with friction. Remove that first.