NEXTSCRIBE

7 Indie Products, 1 Dream: Escaping the 9 to 5 One Side Project at a Time

The Backstory: Why I Started

I wasn’t just building apps... I was building a way out.

Corporate engineering was fine, paid well, but honestly? It felt like I was stuck. Every project I built on the side was me carving out my own little exit.

Something I could actually own.

The Products: Stuff I’ve Actually Shipped

Releasy (Summer 2023)

Tech: Go API, React, Next.js, Strapi, MongoDB, Postgres, Redis

This came from watching QA teams suffer. Like really suffer. Everything was clunky and slow. Releasy was me saying, “What if this didn’t suck?”

Hardest part? Enterprise sales lol. Trying to get big companies to take a chance on a new product is tough. But I learned that trust takes time.

https://www.releasyapp.io

Suparepos (Winter 2023)

Tech: Next.js, Supabase, Stripe, Tailwind

This one’s for devs. You know how many cool repos just sit there collecting dust? Suparepos is a way to turn those side projects into real revenue.

What I realized: Devs aren’t just solving problems... we’re building ecosystems.

https://www.suparepos.dev

Reposter (Spring 2024)

Tech: Next.js, MongoDB

Subscriptions drive me nuts. I just wanted to buy a tool once and use it. Reposter lets you manage socials without that monthly fee stress.

It was personal. I was tired of the rent seeking. This was like... my little protest.

https://www.reposter.app

Supabugs (Summer 2024)

Tech: Go API, React, Next.js, Strapi, MongoDB, Postgres, Redis

Issue tracking feels like solving a Rubik’s cube blindfolded. Supabugs makes it simple. Not just for devs... for designers, PMs, whoever.

The actual hard part? Making it so intuitive people don’t need a manual.

https://www.supabugs.io

Upvoted (Autumn 2024)

Tech: Elixir + Phoenix LiveView, Postgres

I got tired of product teams ignoring what people actually want. Upvoted lets users just tell us what matters. No guessing.

Vulnerable moment. When someone requests a feature, it feels like they’re handing you their trust.

https://upvoted.io

NextScribe (Winter 2024)

Tech: Next.js, Supabase, Tailwind CSS

I like to write, but most blogging platforms are either bloated or just ugly. NextScribe is fast, simple, clean. Built for devs who want to write for free.

Why I built it: I wanted a blog that felt like part of my dev toolkit.

https://www.nextscribe.cloud

ReplyGeek (Spring 2025)

Tech: Next.js, Postgres, Tailwind

Social media is a fulltime job now. ReplyGeek auto generates smart replies to posts using AI. Yeah, it actually works.

Why it exists: I needed to engage more without it eating my life.

https://www.replygeek.com

The Emotional Rollercoaster

Real talk? This path is hard. Some nights I’m hyped out of my mind, thinking I’m onto something big. Other nights, it’s like I dropped a tweet into a void and no one even blinked.

Money-wise? Still got the day job. Not quitting yet. But every product gets me a bit closer. Just not mortgage-paying close... yet.

What I’ve Learned

  • Coding is the easy part. Marketing and support are the real grind.
  • Rejection sucks... but it’s just data. Learn and go again.
  • Indie hackers aren’t competitors. We’re all in this weird boat together.

Dear New Indie Hackers

If you're reading this and feeling that itch to build... just start. It’ll be messy. It won’t be perfect. That’s fine. Just ship the thing.

What’s Next?

No idea, to be honest. But I’m not stopping. Every launch, every bug fix, every random DM... it’s all part of building a life that’s mine.

This isn’t just a dev journey. It’s a life journey.

#web-development #indiehacker
permalink

Dev Life Then vs Now in the AI Era

Alright so if you're like me you've probably noticed dev work ain't what it used to be. We're in the middle of this wild AI boom and honestly it's kinda flipping everything upside down. Thought I’d break it down with some real talk and give ya 10 ways dev life has changed from before AI started showing off.

1. Writing code from scratch vs Just asking the AI

Before You wanted a function you’d crack your knuckles and write that sucker from a blank file. Google was your best friend. Maybe Stack Overflow saved your butt more times than you’d like to admit.

Now You just tell ChatGPT or Copilot “yo make me a function that takes a list of names and returns initials” and BAM done. You barely touched your keyboard. Half the time you don't even read the code until it's broken.

def get_initials(names):
    return [f"{name.split()[0][0]}{name.split()[-1][0]}" for name in names]

see what I mean it’s like magic

2. Stack Overflow was king vs kinda irrelevant sometimes now

SO used to be THE PLACE. Now? I barely go unless the AI gives me some garbage code and I gotta fact check it.

3. Documentation digging vs "lemme just ask"

Remember spending 45 mins scrolling thru some API docs with no search bar. Yeah me neither. Now it’s like

"Hey AI how do I upload a file with axios in React"

and you get a working snippet and maybe even a lil explanation if the model’s feeling generous.

4. Googling 100 times a day vs 10 maybe

Used to live in my browser tabs. Now? Just talk to the AI. Saves me so much context switching and I stay in flow way longer.

5. Code reviews were intense vs “did AI write this?”

Code reviews used to be the place to prove you knew your stuff. Now half the time we're like “did you even write this?” And it’s not even an insult anymore just a legit question.

6. You had to know the whole stack vs now you just bluff till it works

Not saying you shouldn't know your stack but these days you can fake it till you make it with AI help. Like yeah sure I know GraphQL asks AI what even is graphql again.

7. Tests were optional vs now they’re your only hope

AI writes the code cool cool cool but can you trust it?? Nope. So now testing is even more important cause that code might look slick but it's got bugs hiding like gremlins.

8. Debugging was skill vs now it’s also detective work

Before you kinda knew where to look. Now? You’re debugging stuff the AI wrote and you didn’t really understand it to begin with. Feels like being in a crime scene with no clues.

9. Devs were gatekeepers vs now AI leveled the field

Used to be only folks with CS degrees or years of grind could build stuff. Now folks with zero experience are deploying full apps in a weekend. It’s cool and also scary.

10. Burnout was real vs now it's different

Back then burnout was from overwork now it’s like existential. Like will I even have a job if AI keeps getting smarter. Will my skills still matter. What even is programming now.

So what do we do?

Honestly just gotta adapt. Keep learning. Learn to ask better questions. Build stuff with AI not just next to it. Stay curious. Get real comfy being uncomfortable.

Anyway if you made it this far congrats you're either nostalgic or slightly freaked out and same tbh.

#web-development
permalink

React State Management Face‑Off

Got a React app that’s growing fast and your props chain is getting out of hand? Time to pick a proper state manager.

Below we compare Redux, Zustand, Recoil, and Jotai across 12 key points so you can see which one clicks with your style.

1. Learning Curve

  • Redux has more concepts (actions, reducers, middleware) so it feels steeper.
  • Zustand is almost zero‑config: just create a store function and go.
  • Recoil sits in the middle: atoms & selectors are new but intuitive.
  • Jotai is super minimal, just atoms, so you onboard fast.

2. Boilerplate

  • Redux: slices, thunks, action creators.
  • Zustand: a few lines, no ceremony.
  • Recoil: you declare atoms & selectors, leaner than Redux but some setup.
  • Jotai: literally define atoms, that’s it.

3. DevTools

  • Redux: industry standard, time travel & action logging.
  • Zustand: simple plugin with state snapshots.
  • Recoil: official DevTools to inspect atoms & dependencies.
  • Jotai: community tools available, maturing fast.

4. Rendering Performance

  • Redux global store can trigger extra rerenders without memoization.
  • Zustand only rerenders components that use the changed slice.
  • Recoil subscribes only to read atoms, minimizing updates.
  • Jotai independent atoms avoid bulk re renders too.

5. Async Data

  • Redux uses thunks/sagas, powerful but verbose.
  • Zustand handles async inside store functions with ease.
  • Recoil async selectors let you fetch declaratively.
  • Jotai offers atomWithQuery/atomWithAsync for data fetching.

6. Server‑Side Rendering

  • Redux: hydrate initial state on the server.
  • Zustand: create a fresh store per request.
  • Recoil: snapshot & restore atoms during SSR.
  • Jotai: supports hydration via getInitialProps style APIs.

7. TypeScript

  • Redux Toolkit: first class TS support for actions & slices.
  • Zustand: good inference but complex nested types can be tricky.
  • Recoil: types for atoms/selectors can get verbose.
  • Jotai: minimal API keeps TS types simple.

8. Ecosystem & Plugins

  • Redux: mature ecosystem with endless middleware.
  • Zustand: growing community plugins for persistence, devtools, etc.
  • Recoil: backed by Meta with official persistence & utilities.
  • Jotai: modular atoms let you pick only what you need.

9. Debuggability

  • Redux: unmatched logging & time travel.
  • Zustand: basic logging via middleware.
  • Recoil: visualize atom graphs in DevTools.
  • Jotai: DIY logging or use community extensions.

10. Bundle Size

  • Redux + Toolkit: ~70 KB gzipped.
  • Zustand: ~2 KB gzipped.
  • Recoil: ~10 KB gzipped.
  • Jotai: ~1 KB gzipped.

11. Use‑Case Fit

  • Redux: massive apps with complex flows.
  • Zustand/Jotai: small to medium apps craving simplicity.
  • Recoil: declarative derived state & concurrent React.
  • Jotai: atomic graph style state, super modular.

12. Maturity & Adoption

  • Redux: battle tested in countless production apps.
  • Zustand & Jotai: rising stars used by modern startups.
  • Recoil: backed by Meta, still evolving but reliable.
// Zustand quickstart example
import { create } from 'zustand'

const useStore = create(set => ({
  todos: [],
  addTodo: text  => set(s => ({ todos: [...s.todos, { id: Date.now(), text }] })),
  removeTodo: id => set(s => ({ todos: s.todos.filter(t => t.id !== id) })),
  fetchTodos: async () => {
    const res  = await fetch('/api/todos')
    const data = await res.json()
    set({ todos: data })
  }
}))

function TodoApp(){
  const { todos, addTodo, removeTodo, fetchTodos } = useStore()
  React.useEffect(() => { fetchTodos() }, [fetchTodos])
  return (
    <div>
      <h1>My Todos</h1>
      <ul>
        {todos.map(t => (
          <li key={t.id}>
            {t.text} <button onClick={() => removeTodo(t.id)}>x</button>
          </li>
        ))}
      </ul>
      <button onClick={() => addTodo(prompt('New todo?'))}>
        Add Todo
      </button>
    </div>
  )
}

Hope that helps you pick the perfect state solution for your next React gig!

#state-management #react
permalink

Comparing Phoenix and Rails for building a fullstack web app

Hey folks, what’s up? I’ve been diving into Phoenix and Rails lately, and I wanted to share a casual rundown of what I’ve found.

Grab your favorite drink and let’s roll.

Why you might care

Both frameworks let you serve HTML, build APIs, and even add real time features. But they come from different worlds, so your choice really depends on what you value: performance, dev XP, community size…

12 points of comparison

  1. Language

    • Rails runs on Ruby, which reads almost like English and is super beginner friendly.
    • Phoenix is built with Elixir, a functional language on the Erlang VM, so you get actor model concurrency by default.

  2. Concurrency and performance

    • Phoenix rides on the BEAM VM, so handling thousands of sockets or long lived processes is a breeze.
    • Rails can scale too, but you’ll often set up extra threads, use a Puma cluster, or add gems like Sidekiq to match that level.

  3. Productivity and dev experience

    • Rails is famous for being “batteries included”, like generators, built in conventions, scaffolding, etc. You can spin up a CRUD app in minutes.
    • Phoenix has generators too, but it’s more minimal. You might wire up things manually, but you’ll still be flying after a few files.

  4. Templating and views

    • Rails ships with ERB, and the community also loves Haml or Slim.
    • Phoenix uses EEx, which feels a lot like ERB but leaner. Plus LiveView gives you reactive UIs with almost no JS.

  5. Real time support

    • Phoenix Channels and LiveView are crazy powerful right out of the box.
    • Rails ActionCable works, but I’ve seen it get flaky under high load and it’s a bit less mature.

  6. Ecosystem and community

    • Rails has been around for ages; there’s a gem for literally everything.
    • Elixir and Phoenix are newer, so fewer packages, but the community is tight and growing fast.

  7. Database and migrations

    • ActiveRecord in Rails is super intuitive with its DSL and tons of extensions.
    • Ecto in Phoenix is also a DSL but functional; queries feel explicit and you get compile time checks.

  8. Testing support

    • Rails defaults to minitest, and many devs opt for RSpec.
    • Phoenix uses ExUnit, which is simple, fast, and integrates nicely with testing Channels or LiveView features.

  9. Learning curve

    • If you know OOP and Ruby syntax, Rails is a breeze.
    • Phoenix might feel odd at first if you’re new to functional programming, but once you learn pipes and pattern matching, you’ll love it.

  10. Deployment and hosting

    • Rails goes on Heroku, AWS Elastic Beanstalk, Dokku… no sweat.
    • Phoenix apps compile to a BEAM release; you manage a node, but platforms like Gigalixir or Fly.io simplify it.

  11. Scaling

    • Phoenix shines for real time heavy workloads, thanks to BEAM clustering.
    • Rails scales nicely for traditional web requests, but you might spin up more dynos or servers under load.

  12. Hot code upgrades

    • BEAM lets you swap code on the fly for zero downtime if you know what you’re doing.
    • Rails can do phased restarts, but it’s not as seamless as a true hot upgrade.

Example code

Here’s a “Hello world” route in both:

# lib/my_app_web/router.ex
scope "/", MyAppWeb do
  pipe_through :browser
  get "/", PageController, :index
end

# lib/my_app_web/controllers/page_controller.ex
defmodule MyAppWeb.PageController do
  use MyAppWeb, :controller

  def index(conn, _params) do
    text(conn, "Hello from Phoenix")
  end
end
# config/routes.rb
Rails.application.routes.draw do
  root "pages#index"
end

# app/controllers/pages_controller.rb
class PagesController < ApplicationController
  def index
    render plain: "Hello from Rails"
  end
end

Wrap up

So yeah, Phoenix is your jam if you want blazing concurrency and real time magic.

Rails is perfect for rapid dev, huge libraries, and classic full stack CRUD apps.

Both rock, just pick the one that vibes with your team and project needs. Happy coding!

#rails #phoenix
permalink

Gofiber vs Echo for Building APIs in Go

Two Go web frameworks walk into a bar... who wins?

Here’s a list of 10 things I noticed while messing around with both Gofiber and Echo.

Spoiler alert they both good but also not the same vibe.

1. Speed and perf

Gofiber is freakin fast.
Like it’s built on top of fasthttp which is optimized like crazy. You’ll see better latency numbers if you’re into benchmarking stuff.
Echo’s fast too but not Gofiber fast. It’s using the standard net/http under the hood so yknow it’s more traditional.

2. Ease of use

Echo just feels comfy.
The APIs are super clear and not doing anything too weird. You can just sit down and write a REST API without googling too much.
Gofiber can feel a bit different if you’re used to standard Go http.

3. Middleware support

Both support middlewares.
But Echo got a richer ecosystem out the box.
Like you need JWT auth logging rate limiting whatever... Echo prob has a plug for that.
Gofiber has some too but it’s a bit more scattered and sometimes you end up writing your own stuff.

4. Request context

Echo uses Go’s standard context.Context which is great cause it’s what everything else in Go uses.
Gofiber has its own context thing which can be kinda annoying if you tryna pass values around or plug into something like gorm or whatever.

5. Routing

Both support route groups and params and all that jazz.
Gofiber routes are a bit more expressive I’d say. Like you can chain stuff nicely.
Echo’s routing is super solid though and very readable.

6. Error handling

Echo has a solid error handling system.
You can define custom error handlers and respond consistently.
Gofiber has it too but again feels a bit more manual sometimes.

7. Community and docs

Echo been around longer.
So more blog posts stackoverflow answers and all that.
Gofiber docs are nice too but community support is still catching up a bit.

8. Websocket support

Both have it.
Gofiber’s based on fasthttp so it does fine... but you need to be careful cause fasthttp doesn’t support full standard http features.
Echo works with Gorilla Websockets or whatever you like.

9. Deployment

No big diff here.
They both compile to a single binary and work great in Docker or whatever you use.
But since Gofiber is a bit faster you might get better resource usage in high traffic stuff.

10. Learning curve

Echo is just easier to grok if you already wrote stuff with net/http before.
Gofiber kinda does its own thing and takes a sec to get used to.

Bonus Point. Syntax Vibes

Some folks just like how code looks and feels.
Here’s a simple example of a basic API route in both to compare.

Gofiber

package main

import "github.com/gofiber/fiber/v2"

func main() {
  app := fiber.New()

  app.Get("/hello", func(c *fiber.Ctx) error {
    return c.SendString("Hello from Fiber")
  })

  app.Listen(":3000")
}

Echo

package main

import (
  "net/http"
  "github.com/labstack/echo/v4"
)

func main() {
  e := echo.New()

  e.GET("/hello", func(c echo.Context) error {
    return c.String(http.StatusOK, "Hello from Echo")
  })

  e.Start(":3000")
}

Echo code feels more Go-ish.
Gofiber code feels snappy and clean but kinda not standard if you’re picky about that.

So which one should you use?

Gofiber
Use it if you care a lot about speed or building high perf microservices and you're ok with its custom style.

Echo
Use it if you want a super stable well documented easy to maintain API in pure Go style.

Honestly try both for a bit and see what feels better.
Your future self will thank you. Trust me.

That’s it.
Hope that helps.

Feel free to ping me if you wanna nerd out more on Go stuff.

#go #api
permalink