I had a tech background but couldn't build from scratch. AI changed that. Here's the full story.

Neo Gamers — Fri, 05 Jun 2026 08:39:32 +0000

Let me give you the honest version of where I was starting from.

I'm not someone who had zero tech knowledge. I've been around websites for years — buying PHP scripts from CodeCanyon, customising them, setting up hosting, dealing with cPanel, figuring out why some plugin broke everything. I knew enough to be dangerous but not enough to actually build something the way I wanted it.

That gap always frustrated me. I had ideas. I knew what good looked like. But the moment I needed something that didn't exist as a ready-made script, I was stuck. I'd either pay someone to build it, water down the idea to fit what I could find, or just drop it.

I'm in my 40s. That pattern had been going on for a while.

About a year ago I decided to actually close that gap. Not by taking a course or getting a degree — just by building the thing I wanted to build and figuring it out as I went.

Today that site is live at elevato.pro. It has 13 working AI tools, real traffic coming from Google, and I wrote every line of it myself. No CodeCanyon. No template. Built from scratch, exactly the way I wanted it.

This is how that happened.

The difference between customising and building

If you've spent time with CodeCanyon scripts you know the drill. You buy something that's 80% of what you need, you spend a week bending it to fit your idea, and you end up with something that works but never quite feels right. The underlying structure isn't yours so you're always working around it instead of with it.

I wanted to build an AI tools website — image describers, prompt generators, text extractors, that kind of stuff. Clean, free, no ads, no signup walls. I looked for a script I could buy and customise. Nothing close enough existed.

So for the first time I had to actually build it.

I already understood the web well enough — HTTP, how APIs work roughly, what a database is for, the difference between client and server in general terms. What I didn't have was the ability to sit down and write the code myself. That's the piece AI filled in.

The stack

I'll be specific because vague stack recommendations are useless.

Next.js

The whole site runs on this. If you've been in the CodeCanyon world you're probably used to PHP doing everything on the server. Next.js is a different mental model — React on the frontend, API routes on the backend, file-based routing, and it all deploys as one thing.

The part that took me longest to get comfortable with was the App Router — specifically understanding which components run on the server and which run in the browser, and why that matters. Coming from a PHP background where the server just builds the page and sends it, the React mental model of components re-rendering in the browser felt weird at first.

I broke things a lot in the beginning. That's fine. You learn the rules faster by breaking them than by reading about them.

Supabase

I needed a proper database. I'd worked with MySQL through phpMyAdmin before so I wasn't starting from zero, but setting up a database server from scratch, managing connections, handling auth — that was all new territory.

Supabase made this genuinely easy. It's Postgres under the hood, the dashboard is clean, and the connection to Next.js is straightforward. I had it working in an afternoon. The row-level security took me a bit longer to wrap my head around but once I understood it I actually appreciated how clean the approach is.

Vercel

Deployment. This is the part that used to mean buying a VPS, SSHing in, setting up Nginx, hoping nothing breaks at 2am.

Vercel is just a GitHub push. You connect your repo, it builds automatically, it's live. Preview deployments for every branch. Rollback with one click. I don't miss managing servers at all.

OpenRouter

This one deserves more attention than it gets.

OpenRouter is a single API that connects to dozens of AI models — OpenAI, Anthropic, Google, Mistral, a hundred others. Instead of managing separate accounts and API keys and billing for each provider, you go through one place.

The reason this matters for a site like mine: different tools need different models. Some tasks are simple enough that a cheap, fast model handles them perfectly. Others need something more capable. With OpenRouter you pick the right tool for each job and you only pay for what you actually use.

My running costs for the whole site are low enough that I'm comfortable keeping everything free for users. That was the goal from the start.

How I actually used AI to build this

Having a tech background meant I could have a real conversation with AI about what I was building. I wasn't starting from "what is a variable." I was starting from "I know what I want this API route to do, help me write it in TypeScript."

That context made a big difference. But I still had to develop a way of working that actually taught me things rather than just producing code I didn't understand.

The thing that helped most: I stopped asking AI to fix things and started asking it to explain things first.

When something broke, instead of pasting the error and saying "fix this," I started saying "explain what this error means and why it's happening." Then once I understood the problem I'd ask how to solve it. Slower in the moment, but I stopped seeing the same errors repeatedly.

The other thing: when I got code I didn't fully follow, I'd ask it to walk me through it. Not line by line every time, but at least the parts that felt like black boxes. Coming from a background of buying other people's code I was used to not understanding what was inside things. Building my own meant I actually wanted to know.

The conversations that taught me the most weren't the short ones. They were the ones where I kept pushing — "why did you structure it that way," "what would break if I changed this," "is there a simpler version." That back and forth is where most of the real learning happened.

The mistakes

I over-engineered the first version.

Having just enough knowledge to know what good architecture looks like is dangerous. I spent time setting up things "properly" before I had anything working. A clean folder structure means nothing if the product isn't shipped. I should have gotten something live faster and cleaned up later.

I built features nobody asked for.

I spent a week on a feature that let users save their tool outputs. Thought it was a smart addition. Nobody uses it. I should have shipped two more tools instead. Build what people actually need, not what seems clever at the time.

I ignored SEO for too long.

I came from a background of customising sites that already had traffic baked in from the marketplace. Building from scratch meant I had to earn that traffic myself and I underestimated how much work goes into it. Six months in I had a working site with barely any visitors because I hadn't thought seriously about what people were searching for. Had to go back and redo a lot of the content and structure.

I kept wanting to rewrite things.

Every time I learned something new I'd look at old code and want to rebuild it the right way. I had to force myself to stop. The site works. Users don't care about the code quality. Ship and improve forward, don't rebuild backward.

What I actually built

Elevato is a collection of free AI tools — describe an image, extract text from a photo, generate prompts for Midjourney or Flux, translate prompts, remove image backgrounds, summarise YouTube videos, write and edit content. Everything is free, no account needed.

It's not the most sophisticated codebase in the world and I know it. But it's mine, it does exactly what I wanted it to do, and building it from scratch rather than bending someone else's script to fit — that part still feels good every time I think about it.

What I'd tell someone in the same position

The CodeCanyon mindset is a ceiling. There's nothing wrong with using ready-made solutions when they fit. But if you've been doing that for years and you have ideas that don't fit any script you can find, it's worth pushing past it. The gap between "can customise" and "can build" is smaller than it used to be.

Next.js + Supabase + Vercel is a solid stack for this. Good documentation, big community, and AI assistance works well with all three because there's so much training data on them. If you're coming from a PHP background expect the mental model shift to take a few weeks. It's worth it.

OpenRouter is underrated. If you're building anything with AI and you care about costs, go look at it before you commit to a single provider.

Use AI as a colleague, not a code dispenser. The difference in what you actually learn is significant. Ask why, not just how.

Ship earlier than feels comfortable. Coming from a world where you could preview a CodeCanyon demo before buying, it's tempting to want your own thing polished before anyone sees it. Resist that. Real feedback from real users is worth more than another week of tweaking in private.

Last thing

I still wouldn't call myself a developer in the professional sense. People who do this for a living and have done it for years are operating at a different level and I respect that.

But I build things now. Things I designed, things that work the way I wanted them to, things that exist because I made them rather than because I found them on a marketplace.

For me, after years of hitting that ceiling, that's the whole thing.

DEV Community: Neo Gamers