DEV Community: FromZeroToShip

#20 Your First 30 Days With AI: A Simple Plan

FromZeroToShip — Tue, 21 Jul 2026 12:26:00 +0000

The rules and the tool list are useful once you're moving. But the question I actually get most is smaller: okay, so what do I do on day one?

Here's the plan I'd actually give someone standing exactly where I stood. Thirty minutes a day. No studying. Four weeks.

Week 1 — Just get comfortable talking to it

Don't try to learn anything yet. Open an AI chat and talk to it about whatever's in front of you — ask it to recommend lunch, ask it an Excel question, ask it something you're a little embarrassed to ask a person. It doesn't matter what.

The only goal this week is to feel, in your own hands, how far "just ask" actually reaches. That feeling — oh, it can do that too — is the entire foundation. You're not building anything yet. You're finding out what's possible.

Week 2 — Pick one annoyance

Choose one thing you do over and over that genuinely irritates you. Don't reach for something ambitious. The smallest, most frequent annoyance is the right one — not the biggest problem you can imagine solving.

Describe it to the AI in plain words and start talking through how it might be reduced. You're not building yet, just figuring out the shape of the fix together. This is the same question that opens half the stories on this blog: what's the one repetitive thing that wastes your time every week?

Week 3 — Build the smallest possible version

Take whatever you landed on in week 2 and move it into a spreadsheet. Ask the AI to write the formula. Let it automate one calculation you used to do by hand.

It doesn't need to be impressive. One click producing something that used to take you ten minutes is a complete win for this week. This is exactly how a single stuck formula eventually became a real tool — it just never stopped at "one formula."

Week 4 — Show it to one person

Show what you made to a single coworker. "Want to try this?"

If it makes their day even slightly easier, you've already started for real. That one small reaction — someone else's relief — turns out to be the biggest fuel there is for building the next thing. Noticing other people's annoyances, not just your own, is where this whole habit actually turns into something bigger than a personal trick.

What to expect a month from now

Nothing dramatic. You will not feel like a developer. You'll just have one small, working thing that didn't exist thirty days ago.

That's exactly where I started too. One small thing, kept going, quietly became twenty-two.

The plan only works if you actually pick something this week — not the ideal project, just the nearest annoyance. Everything else follows from that one small, unglamorous choice.

This is part of From Zero to Ship — the honest logbook of a non-developer who shipped 20+ working tools with AI. If this resonated, the rest of the series is there.

#19 My Actual Tool Stack: No Coding Background Required

FromZeroToShip — Mon, 20 Jul 2026 12:25:00 +0000

People keep asking for a list. Fair enough — across eighteen posts, tools kept showing up one at a time, buried inside whatever story I was telling. Here they all are in one place.

Nothing here is exotic. Most of it is free. None of it required a computer science background — just me, and each tool, one problem at a time.

The AI

Gemini was the first one I ever opened, back when a stuck spreadsheet formula forced my hand. It answered questions in plain language, which was the whole unlock at the time.

Claude came later, after a phone call with a stranger who'd started exactly where I had. The difference between the two wasn't small: one told me about code, the other just wrote it. If you're only picking one place to start, start by asking it questions in your own words and seeing what comes back — no special phrasing required.

Google Sheets

This is where everything began. It looks like Excel, but several people can type into the same sheet at the same time, live. That single difference is what let six mismatched paper forms become one shared table.

Underneath it sits Apps Script — a small scripting layer built into the sheet itself. That's how a spreadsheet formula eventually grew into a button, and how that button eventually grew into a real screen.

VS Code

Once tools needed more than a spreadsheet could hold, I needed somewhere to actually write and run code with an AI's help. VS Code was the one I picked, mostly because it didn't scare me the way a plain black terminal did. That's the moment the real building started.

NAS

A NAS is just a small storage box that sits in the building and never turns off — the kind of thing offices already have for shared files. I had a hunch it could do more than store files, and that hunch turned out right. Once I got access and moved things over, everything got dramatically faster, and it became something closer to our own private server.

Cloudflare

The first time a tool needed to reach past our own walls, Cloudflare is what built the door. It's free, and it handles the security side properly instead of leaving a hole open. That first outside connection changed how I thought about everything.

Tailscale

Different problem, similar shape: a private tunnel, but this one just for me. It let me reach into our systems from anywhere and fix things without driving back to the office at midnight — a detail that mattered a lot more once things started depending on staying up.

Open source

Plenty of the pieces I needed, someone else had already built and given away for free. Before assuming something has to be built from scratch, it's worth checking whether it already exists. That single habit saved more time than any tool on this list.

What this list actually proves

None of this is a shopping list. It's evidence of a shape: a small, mostly free tool, picked the moment an actual problem needed it — never bought in advance, never picked because it looked impressive.

Every tool here entered the story because something specific was broken and this was what fixed it. That order matters. Pick the annoyance first. The tool will be obvious once you're standing in front of the real problem.

This is part of From Zero to Ship — the honest logbook of a non-developer who shipped 20+ working tools with AI. If this resonated, the rest of the series is there.

#18 Six Rules I Learned From a Year of Working With AI

FromZeroToShip — Sun, 19 Jul 2026 14:24:00 +0000

Every post so far has been a story. This one is different.

People have started asking me a plainer question: okay, but how do you actually talk to it? Not the drama, just the method. So here it is — the six rules I actually learned, plus the real conversations behind them, mistakes included.

This isn't a technique. It's closer to an attitude, hammered into shape over a year of getting things wrong.

The six rules

1. Don't take "it can't be done" at face value.
AI states limits with total confidence, and sometimes it's simply wrong. Ask again. Ask differently. My biggest breakthrough came from a place AI had already declared impossible.

2. Ask for one thing at a time.
Stack too many requests into one prompt and everything tangles. Break it small, get one piece working, then move to the next. It feels slower. It isn't.

3. Make a copy before you let it touch anything.
AI breaking something that used to work is more common than you'd think. Copy first. If it goes wrong, you have somewhere to go back to.

4. Write down what worked.
Tell the AI the pattern that succeeded and it stops repeating the same mistake. Failures are worth keeping too — a list of dead ends is still an asset.

5. Keep the process simple.
The same result through a tangled process costs more every time — more time, more money, more chances to break. Simple is cheaper and faster, almost always.

6. Say "I don't know" out loud.
Don't perform expertise you don't have. "I have no idea what this is, explain from zero" gets you a better answer than pretending you followed the first one.

What asking actually sounded like

No secret phrasing. Just plain description of what I wanted, admitting up front that I didn't know the technical words for any of it.

"I want this cell to turn red if it's bigger than that cell, but I don't know any code. Explain from the start."

"I want one button. Press it, and the scattered rows line up by date. Is that possible?"

"This screen gets slow when a lot of people use it at once. Walk me through why, and whether there's a fix."

That's the whole trick. Say what you don't know, describe what you want in ordinary words, and the AI meets you where you are.

Where AI actually got it wrong

Trust it. Just not blindly. These are real ones.

The fake limit. When an internal tool I'd built slowed to a crawl under real traffic, AI told me flatly: that's just the limit of the server, nothing to be done. I couldn't accept that answer, so I kept pushing on it, night after night. The real cause was somewhere else entirely — the tool re-fetched everything from scratch on every click instead of remembering what it just loaded. Fix that one thing, and the "hardware limit" evaporated. The limit wasn't the server. It was not questioning the AI's confidence.

The outdated screen. Setting up outside access for the first time, the steps AI described kept not matching what was actually on my screen. Its knowledge had a cutoff date, and the interface had moved on since. The fix was just telling it back: "here's what I'm actually seeing now" — and it adjusted from there.

The thing it deleted. Early on, asking for one small fix would sometimes wipe out something else that had been working fine. That's exactly why rule three exists. Even now, with much better tools, I still make the copy first. Old habit, still worth it.

The one-line version

Say what you don't know honestly — but question "it can't be done" one more time. And always make a copy before you touch anything.

Those three lines cost me the most, across an entire year, to actually learn.

A month from now, none of this will feel dramatic. You'll just have one small tool sitting there that you built. That's exactly where I started too — one small thing, which quietly turned into twenty-two.

Your first one is next. Go find the annoying thing.

This is part of From Zero to Ship — the honest logbook of a non-developer who shipped 20+ working tools with AI. If this resonated, the rest of the series is there.

#17 None of It Was for Me: A Year of Building With AI

FromZeroToShip — Sat, 18 Jul 2026 14:20:00 +0000

I laid them all out one day. Twenty-two tools I had built over a year.

Then I noticed something strange. Not one of them was for me.

Every tool was for someone else

I looked down the list and it was the same story every time.

There was a tool for the coworkers who counted hand-hygiene moments by hand. One for the staff member who stood out in the sun writing down license plate numbers. One for an older employee who found video editing impossible. Several for patients. Every single one was built for somebody else. The thing that struck me: I never built a tool to make my own day easier. Not one.

What surprised me most was that I never planned it that way.

I never once sat down and decided "I should build things for other people." That was never the goal. I just couldn't stand watching someone struggle in front of me, so I'd build something to fix it. I'd do that, then do it again, and after a year I turned around and found that all of it pointed outward. Nobody asked me to. I didn't have a plan. I guess that's just the kind of person I am. And I only learned that about myself after the twenty-two tools were already done.

What actually made it possible

But when I ask what made any of this possible, the answer keeps landing in one place. It was AI.

I want to be clear about this, because it's easy to get wrong. A person who didn't know what code was built twenty-two tools in a year. That didn't happen because I suddenly got smart. It happened because a tool called AI landed in my hands.

And using it taught me one big thing. The world changed.

Before AI, being good with a computer was your ability. If you could format a clean document, if you could write a slick spreadsheet formula, that was a real skill on its own. People got jobs for it. That era is fading. Now the computer is just a tool, and AI is just a tool. What matters is how well you can drive it. Your ability to use AI is becoming, more and more, your ability itself.

AI holds everything; you only need a sliver

Here is the part it took me a while to understand.

AI holds an enormous amount inside it. Nearly every field of knowledge, all at once. But what I need at any given moment is one tiny sliver of that. So the real skill isn't knowing things. It's pulling out the one piece you need from that giant pile.

And how you ask shapes what comes out. Ask one way and the same AI becomes a mathematician. Ask another way and it's a scientist, or a writer. For me, it became a developer. I stood the AI up as my developer, asked for what I needed, and used what came back. That was the whole trick.

This blog is no different, honestly. I'm not a native English writer. These posts get written with an AI as my writing partner — I tell it my story, in my own language, and we shape it into something you can read. A non-developer who built software with AI is now telling you about it with that same AI. The way these words get made is the proof of the point they're making.

So here's what I tell people

I work with staff who are nervous about all of this, and I always say the same thing.

Don't try to study it like a serious subject. Just play with the AI. Ask it this, ask it that. Get the feeling of oh, it can even do that. Once you have that feeling, you start asking for harder things without noticing. That's how it grows — one person, one small ask at a time.

I don't think everyone needs to lead the wave. But you should at least keep up with it. I'm not out front either. I just put my feet in the moving water and walked hard enough not to be swept off.

You don't have to be ahead of the curve. You just have to refuse to stand still.

Your turn

Walking like that, keeping up, I looked up one day and I was here. Twenty-two tools. A year I never could have predicted. A skill I never thought belonged to people like me.

This series started with a pile of paperwork I couldn't stop staring at, and it's brought me all the way to this: the quiet realization that the most useful thing I learned wasn't code at all. It was how to ask.

So now I want to hand the story to you. You have your own pile of paperwork. Your own coworker struggling in front of you. Your own one tiny sliver to pull from that giant pile.

Go play with it. See what it can even do. The next story is yours to build.

This is part of From Zero to Ship — the honest logbook of a non-developer who shipped 20+ working tools with AI. If this resonated, the rest of the series is there.

#16 In the End, It Was Always About People

FromZeroToShip — Fri, 17 Jul 2026 13:01:00 +0000

One day the hospital decided to make short promo videos.

Short video is everywhere now, so a lot of staff jumped in. Plenty of good clips came out of it. But not everyone could play. Some of my coworkers weren't comfortable with computers. They had the photos. They had the footage. They just didn't know how to edit any of it, so they made nothing at all.

One of them was a manager in our administration office. She told me she had all the raw material, but video editing felt impossible. She wanted to try. She couldn't bring herself to start.

I started building that same day. The goal was simple: a video editor anyone could use.

Build for the person who struggles most

Everything I make follows one rule. It has to be easy. Comfort for the user is always priority number one.

There's a reason. The people at my hospital range from barely twenty to past sixty. Younger staff grew up with screens. For older staff, a single small button can be a wall. If I want nobody left out, the tool has to work for the person who finds it hardest. Not the power user. The most unsure person in the building. That's the bar.

Rebuilding the features of a paid editor like CapCut, for free, came with limits. But there were ways through. Automatic subtitles were the surprise. I bolted on a speech-recognition tool called Whisper, and it transcribed speech into text better than some famous commercial apps. It just listened and typed.

Staff started editing video with no trouble. I called the tool EasyReel.

What I was actually trying to build

Here's the thing. I didn't really care about a video editor.

What I wanted was to give older staff an experience. The feeling that AI lets you do the thing you'd written off for life. The thing you never dared to attempt. Not me explaining it. Them doing it, with their own hands.

The coworker past sixty who gave up because she couldn't edit. The moment she finishes a video herself. I wanted to see her face in that moment. That's different from just saving someone work. It's taking a person who couldn't, and making them someone who can. Not pity. Putting the thing in their hands and saying: you can do this too.

Reaching the patient, not just the staff

Then I built something that reached past the staff and touched the patients.

It's a cognitive-rehab tool I called EasyBrain. Cognitive rehab means training to recover functions like memory and attention. For this, my hospital was paying for a program that cost about 40 million won — roughly USD 30,000. To me the features weren't that impressive. The price was.

I couldn't just be reckless about it. To formally bill for this treatment, regulations require an officially registered program. So whatever I made could not replace the official one. I had to draw that line clearly, and I did.

But I flipped the question around. What if I didn't bill at all? What if it was only a free helper, an extra tool to give patients more practice? If patients could train more without spending a single won, why wouldn't I make it?

I also had an edge nobody at a software company has. I treat the patients and I build the tool. So I could try it on a real patient, watch the response, and fix it on the spot. No company can do that. The end of our work is the patient getting better. If I can help that for free, that's just the road to take.

Twenty-two tools, one direction

It went like this, over and over.

I gave back the hands that cropped and retouched a photo every time we made an employee ID card. I made it so a director could search one keyword instead of digging through years of paper diaries. I tracked treatment adherence so no patient slipped through without the care they were owed.

Line up all twenty-two tools and they look like different programs. They weren't. They all pointed at the same place.

Lighten someone's hands. Make someone able. Help someone heal. In the end, every one of them was a person.

So if you're a non-developer wondering what to build first, here's the only filter that has held up for me: don't start with the coolest idea. Start with a specific person who's stuck, and build the smallest thing that unsticks them.

And then, after staring at all twenty-two laid out in a row, I noticed something strange. But that's the next story.

This is part of From Zero to Ship — the honest logbook of a non-developer who shipped 20+ working tools with AI. If this resonated, the rest of the series is there.

#15 Why Each Tool Got Easier to Ship: Drawing My Own Navigation

FromZeroToShip — Thu, 16 Jul 2026 13:00:00 +0000

Making new things kept getting easier. At first that surprised me. Then I looked closer, and I saw why.

My first tool started from bare dirt. Putting a single screen on the page took me days. Saving data took me days. Everything was a first. But the second tool came a little faster. The third was faster still. A problem I had already solved once, I never had to solve from scratch again. I would grab something I had already built, change a few parts, and the new thing would appear quickly.

The know-how was piling up. Without noticing, I had built a kind of frame inside myself. I no longer started every tool from the ground. I started on roads I had already paved.

Failures became data

The same thing happened with my failures.

I failed in a huge number of ways. Do it this way and it tangles. Do it that way and it slows down. Do it the other way and it collapses. The old me would have let those failures float by. I stopped letting them float. A way that didn't work, I remembered, and I never walked that road twice. A way that did work, I wrote down as a rule and handed to the AI to remember. So next time, I didn't repeat the same mistake.

For a long time I had believed I never lose anything by failing. Now that belief moved up a level. My old failures got blurred into one vague word: experience. Now, finding one road that doesn't work was data, all by itself. Failure stopped being a soft comfort. It stacked up as concrete material for drawing the next route.

I was drawing my own navigation

Looking back, the whole thing was like building a navigation system for myself.

At the start I had no map. Nothing told me which road led to the destination. So I tried this way and that way. I backed out of dead ends. I wandered down the long way around for ages. But as those wandered roads collected, one by one, a map slowly drew itself. This spot is blocked. Go that way and it's fast. This road is the safest. I came to know it in my body.

Experts probably start with that map already in hand. I didn't. I had no map, so I drew it with my own feet. And because of that, the map was completely mine. It wasn't a road someone handed me. It was a road I cut while lost. So nobody knew it better than I did.

The loop that became second nature

Once the map was there, every new tool followed the same simple path. It went like this:

Interest. Something catches my attention. Usually a small annoyance, or a thing someone wishes worked better.
Search and learn. I look it up. I find out what already exists and what other people have done.
See a direction. Out of all that, one rough direction starts to stand out.
Find a method. I figure out the concrete way to get there, often by reusing good open source.
Just execute. I stop weighing whether it'll work. I assume it will, and I start.

That last step changed the most. I used to think first and ask should I try. Now I don't pause there. I assume it can be done, and I begin.

One sentence, one day, one tool

Here is what that looked like in practice.

A manager in the administration office mentioned something in passing. He had to read work documents on his phone, but ads kept popping up and made it miserable. The old me would have stalled on maybe I'll build something. I didn't stall. Before deciding if it was possible, I assumed it was, and I started. It went exactly as he described.

I pulled in good open source that was already out there in the world. I laid it on the map I had been drawing all along. In one day, a tool came out. It read documents fast, with no ads. I called it EasyOffice. Staff liked it. Quick, and no ads.

A single sentence of conversation becoming a working tool the same day. For someone who once clawed at one tiny thing two hundred times over, that speed was unthinkable.

That's the real shift, and it's the one universal thing I can hand you: the point of every failure isn't the lesson; it's the map underneath your next attempt.

What got clearer as it got faster

One became two. Two became four. Before long the count passed twenty.

Here's the strange part. The faster I built, the sharper one thing got. Why am I making this. Who am I making it for. The more speed I picked up, the more often I stopped in front of that question.

And the answer always pointed at a person. That's where this goes next.

This is part of From Zero to Ship — the honest logbook of a non-developer who shipped 20+ working tools with AI. If this resonated, the rest of the series is there.

#14 Building an Intranet to Replace Our Scattered Group Chats

FromZeroToShip — Wed, 15 Jul 2026 12:53:00 +0000

When I moved to the planning office, the first big job that landed on me was counting.

For years I had watched other people do it from the sidelines. I knew it was painful. I knew someone suffered through it every quarter. But it wasn't mine. Now it was. And the moment a problem becomes yours, you stop seeing it as background noise. You start seeing every wasted minute up close.

A count of 48,000

The hospital where I work runs a daily gratitude practice. Every staff member writes a short note about something they were thankful for that day. It's a good idea. Nothing wrong with the idea.

The problem was that we had to count it.

Every quarter we tallied who wrote how much. About 48,000 posts piled up in a single quarter. And it wasn't just adding up a number. A person had to read each entry and confirm who wrote it, on which day, in the right form.

The posts went up on Daum Cafe, a Korean community board, because we had no system of our own. So people posted however they liked. Different titles. Different formats. Different nicknames. Half the time you couldn't tell if two posts came from the same person. Before you could count anything, you had to match names to people. We burned ourselves out just figuring out who was who, before the counting even started.

Three of us in the planning office spent a full week on it. Alone, it would have been three weeks. And that was only the final pass. Before us, each department's clerk counted their own people first. Add up everyone who counted and everyone who checked, and twenty to thirty people were tied up in this every quarter.

What you saw was a few stacks of paper on a desk. What was actually happening was the whole hospital repeating the same work by hand, four times a year.

It wasn't just the count

The deeper I looked, the more I realized the count was a symptom.

We had no shared system at all. Announcements went out on Band, a Korean group app. Department chatter happened on KakaoTalk, our messaging app. The gratitude posts piled up on Daum Cafe. Whenever we needed something, we grabbed whatever consumer app was handy.

For staff, this was miserable in a quiet way. KakaoTalk is where your friends and family live. It's personal. And work orders kept arriving there. You'd be lying in bed at night and a department group chat would buzz. Work and private life had bled into each other.

Both halves bothered me. I wanted the count to disappear. And I wanted to pull all the scattered pieces into one place, so that a person's private life and their job could finally be clean and separate.

The plan formed in my head

The fix was clearer than I expected.

If every staff member had a fixed name in the system, and posts had a fixed title and format, then the moment someone wrote one, it would be logged correctly. The counting would simply vanish. The number you saw would be the fact. No tallying, because there was nothing left to tally.

The scattered apps were the same shape of problem. Give every kind of message one home — announcements, chat, posts — and work would stop leaking into people's personal phones.

In my head, the whole thing was already drawn.

The biggest thing I had built

So I decided to build it.

Honestly, I'd started before the job was even handed to me. Back in mid-March, while I was still working in the therapy room, I had quietly begun building this intranet. I'd been watching these problems for a long time, itching to fix them. When the count became my responsibility, I just pushed harder.

This was a different scale from anything I'd done. Everything before had been a small tool that helped with one task. This had to replace whole apps — announcements, messaging, the gratitude posts, department boards, all the scattered places at once, folded into a single hub.

I poured everything I'd learned into it. I put it on a NAS, the little server box in our office. I opened a path so it could be reached from outside. And night after night, with Claude beside me, I stacked it up one piece at a time.

If you take one thing from this, take this: you don't need to know how to build the big thing on day one. You need a problem clear enough that the shape of the solution is obvious — then you build toward that shape, one small piece at a time.

I named it EasyONE. The scattered things, pulled into one. I'd been slapping "Easy" on my tools for a while, the wish that things could be simpler. This time I added "One."

The launch

On April 14th, I opened EasyONE to the staff.

It was a trial run at first. I was still nervous. Everything I'd made before was used by one person, or one department. This was different. This was a screen every employee in the hospital would open every day. It was the first time I was putting something I'd built by hand in front of 660 people.

And I was proud. A man who hadn't known what code was had built a system for an entire hospital and was handing it over. A solid month of work. I had the confidence that month bought me. I thought I'd prepared everything. Now the staff just had to use it.

That's what I believed, right up until that afternoon.

Then the afternoon came. But that's the next story.

This is part of From Zero to Ship — the honest logbook of a non-developer who shipped 20+ working tools with AI. If this resonated, the rest of the series is there.

#13 The Day Everything Changed: Meeting a Self-Taught Builder

FromZeroToShip — Tue, 14 Jul 2026 12:52:00 +0000

For a long time, building software felt like a thing I was doing in secret.

I was a physical therapist. I saw patients all day, then stayed late to build little tools that made the hospital's busywork hurt less. Nobody assigned it. Nobody could help me with it. I had no one to ask. I just kept poking at problems alone, in the gaps between my real job.

Then one day, in a city called Andong, two things happened at once. Both of them changed everything.

Meeting the person on the other end of the phone

There was a software founder I'd gotten to know — until then, only a voice on the phone. As it happened, he had a golf outing near my hospital, and he stopped by on the way. So there we were, sitting across a meeting table for the first time.

I opened up one of my tools. It was an inventory search I'd built for the hospital — hundreds of thousands of supply items, findable in a single search. A few days earlier I had finally fought my way through setting up outside access, so the screen loaded fine, even on the meeting room WiFi. I showed him.

Then he showed me his work. He ran a distribution company, and he had used AI to automate the product photos and marketing images his design team used to make one by one in Photoshop. Now anyone at the company could press a few buttons and get something good.

It was a strange feeling. We were doing the exact same thing. I had put real work into the hands of ordinary staff. He had put design into the hands of ordinary staff. Different companies, different jobs, but the same idea: take something only an expert could do, and open it up to everyone.

The one sentence I still carry

That day he said something that stuck with me.

He told me, more or less: assume you can build almost anything. Good open source is out there for free. Don't fold before you start. Just begin as if it'll work, and as you go, it usually does.

That was the first time I'd heard the words "open source." Somebody, somewhere, builds useful pieces of software and gives them away — pieces sitting there waiting to be used. Half the things I had been grinding out from scratch, alone, already existed in some form.

But the part that moved me wasn't the technology. It was the attitude. Don't fold before you start. That was already how I lived, in a quieter way — try it, and if it works, great; if it doesn't, I learned something. He just said it bigger and clearer than I'd ever let myself say it.

Seeing how far the road could go

Here's the thing that gave me the most courage: he wasn't a developer either.

He had never learned to code. And yet this non-developer had built an entire AI research effort inside his own company. He had even built his own custom working tools. (I tried to copy that part later and gave up fast. That's fine. You don't have to copy everything.)

Up to that point I'd been completely alone. No one beside me on the same path. And now I was looking at someone who had started from the same place I did and gone much, much further. So there was something at the end of this road. I could get there too.

If you're building something on your own and feel like the only one doing it, find one person who started where you are and went further. You don't need a mentor or a teacher. You just need proof the road leads somewhere.

A new desk, and a real weapon

The same day, something else happened.

A director called me in and asked if I could help out in the planning office — the part of the organization that works for the whole foundation, not just one therapy room. There was no formal transfer, no ceremony. I just started showing up there.

But the meaning wasn't small. Until then, I had built everything on stolen time, after hours, as a side thing I did because I liked it. Now it was becoming work I was allowed to do out in the open. The day my tools changed, my place started to change too.

So I fixed up how I worked. The founder had told me to use Claude in the terminal — that black, blinking screen — because it was more powerful. But that black screen scared me. I barely understood computers. So I found a middle path: VS Code, which looks a lot like Cursor but keeps the power. It felt familiar, and it stuck to my hands fast.

That was when I finally had a real weapon. Looking back, this is where the serious building actually began. Someone who had started with nothing but a few stubborn questions now had a proper tool and a proper desk.

Next came the biggest thing I'd ever attempt: pulling everything I'd scattered across the hospital into one place. But that's the next story.

This is part of From Zero to Ship — the honest logbook of a non-developer who shipped 20+ working tools with AI. If this resonated, the rest of the series is there.

#12 The First Time I Opened a Door to the Outside Internet

FromZeroToShip — Sun, 12 Jul 2026 14:00:00 +0000

For months, all of my tools lived inside the building.

They ran on a small server in the hospital, on our own internal network. You could only reach them if you were physically connected to that network — sitting at a hospital desk, on hospital Wi-Fi. To anyone on the outside, they didn't exist. No address, no door, no way in.

I told myself that was the safest possible setup. Nothing ever left. Nothing could get in. And I meant it. Early on, a senior colleague had told me about a place that got hit by an attacker from the outside who locked their entire server and held it for ransom. That story stuck with me. So I'd promised, out loud, that my tools would stay inside. The door to the outside would stay shut.

Then I had to open it.

A demo I couldn't show

I'd arranged to meet someone in person to show them what I'd built. I wanted to bring something real, not just talk. So I picked the tool I was proudest of — an inventory and supplies tool I'd called EasyFS. It had the most data and the most hours of my life in it.

We met in a hospital meeting room. I opened my laptop. And I hit a wall.

The meeting room had no wired connection, so I had to use Wi-Fi. But that Wi-Fi wasn't connected to our internal network. So there I was, sitting inside the hospital, unable to reach a tool that only ran inside the hospital. The data was sitting right there, in the same building, a few walls away. I couldn't touch it.

The only way to reach something inside the building was to go all the way out and come back around. To show my tool, I had to make it reachable from the outside.

And that meant opening the exact door I'd promised to keep shut.

The promise I had to break

I was scared. Honestly scared.

The ransomware story replayed in my head. If I opened the wrong door and something like that happened to us, it would be my fault. Not a vendor's, not some smart engineer's at a faraway company. Mine.

So the question narrowed down to one thing: how do I get to the outside as safely as possible?

I did what I always do. I started asking. Is this method safe? What about that one? I asked and compared and asked again. The answer I kept landing on was Cloudflare.

It builds a protected tunnel so traffic can move between the outside world and your own server without exposing it directly. The more I read, the less I believed it. It was supposed to be seriously secure — and it was free. Free? I checked that a few times.

Following instructions that didn't match the screen

The hard part wasn't deciding. It was the setup.

I worked through it with Gemini, asking it what to click next. But the screen it described kept not matching the screen in front of me. The menu it told me to find wasn't there. The button had a different name. For a while I thought I was the one doing something wrong.

Then it clicked. The AI had learned from an older version. Cloudflare had changed its interface since then, and the AI didn't know. It was confidently describing a screen that no longer existed.

That's a thing worth knowing early: an AI can be completely sure and completely out of date at the same time — so when its instructions don't match reality, trust the screen in front of you, not the AI.

So I felt my way through. Build the tunnel. Attach an address. I'd think I was done, and the connection would fail. I'd hunt for the mistake, fix it, get blocked again, fix it again. After a long stretch of fumbling, it finally happened: EasyFS opened from outside the hospital.

For the first time, one of my tools had gone over the wall.

One door opens, and the work changes

Once it worked, I realized this wasn't a one-time demo trick.

If staff could reach the tool from outside, they could check supplies from their own phones, anywhere. I'd been imagining QR codes stuck on each item — scan one with your phone and that item's information pops up. That whole idea only worked if the tool was reachable from the outside. So while I was in there, I built the QR lookup too.

By then it was clear I needed a real address. Not a tangle of network settings, but a proper name people could type and find. I went to one of our directors, explained why it mattered, and we bought a domain on the spot. For the first time, we had our own address on the open internet.

My tools, which had lived so safely inside, had taken one step toward the outside world. And that was the moment I started taking security seriously for the first time. When nothing ever leaves the building, you don't have to think about who might be knocking. The moment you open one door, you do.

A few days later, I walked through that door and met someone on the other side. But that's the next story.

This is part of From Zero to Ship — the honest logbook of a non-developer who shipped 20+ working tools with AI. If this resonated, the rest of the series is there.

#11 When AI Coding Tools Were Dumb (and Nights Were Fun)

FromZeroToShip — Sat, 11 Jul 2026 14:00:00 +0000

I had decided to move everything onto our own server.

The hospital ran a small NAS — a box on the network that stores files and can run little programs. My plan was to lift the tools I'd been hacking together and put them there, where coworkers could actually use them. Good plan. Moving them turned out to be a slog.

Around then I found Cursor. It's a code editor with an AI built into it. Before, I'd ask Gemini a question, it would hand me some code, and I'd copy that code by hand, paste it into the right place, and try to fix it. With Cursor, I connected the AI right into the editor and just told it what I wanted. Build this. Fix that. It edited the code itself. People call this "vibe-coding" — making software by talking to it.

It sounds like a dream. And honestly, back then, the tool was terrible.

Dumb, and a little mean

Don't picture today's AI. The vibe-coding of that era wasn't just dumb. Some days it felt spiteful.

Here's what it did. I'd ask it to fix one part of the screen — call it section A. It would fix A. Then it would quietly delete B, C, and D — the parts that were working fine — and leave A sitting there alone. I asked for one change. I'd come back and find that hours of work had vanished.

And there was no safety net. No real undo. No autosave worth the name. Once something was gone, it was gone.

My stupid, beautiful workaround

So I did the dumbest thing that worked. Before I changed anything, I copied the whole project and saved a spare. Make a copy, edit. Make another copy, edit again. If the AI nuked everything, I could fall back to the last good copy.

I stacked copies on top of copies. Copy 1, copy 2, copy 3. I crept forward one square at a time, dragging a trail of backups behind me.

This is the part I want you to hear, because it's the part nobody tells you: the embarrassing manual workaround is allowed. You don't need the elegant method. You need a method that lets you keep going when the tool betrays you. Folders full of final, final_v2, final_REAL are not a sign you're doing it wrong. They're a sign you're still moving.

It was painfully slow

Moving a single program onto the NAS took days. Days.

Today I'd hand the same job to a modern AI and it would be done in about ten minutes. I'm not exaggerating. The thing that now takes ten minutes once cost me several full nights of stacking copies and inching ahead.

If someone had watched me, they might have thought I was wasting my time. Why grind through that by hand? It's a fair question. I didn't have a good answer at the time.

The strange part: I had fun

Here's what I didn't expect. I enjoyed it.

Every night the program got a little better, and I could see it happen. A button that didn't work yesterday clicked today. A crooked layout snapped straight. A number that had been wrong came out right. Those tiny wins were oddly addictive. I'd look up and it was 2 a.m. Fix one square, feel good, reach for the next one.

It was hard and it was fun at the same time. Those two aren't opposites. The difficulty was why the small wins tasted so sweet. If it had been easy, getting a button to work wouldn't have meant anything.

Looking back, the thing that kept me going wasn't some grand sense of mission. It was simpler than that. This was fun. That fun alone got me through those long nights with that dumb little tool.

Why this matters if you're starting now

It's tempting to wait for the tools to get good. They're far better now, and that's real. But the tools were never the point.

The point was the small, daily proof that I made this work. You can get that today with way less pain than I went through — and that should make starting easier, not scarier. The slow version still taught me everything. The fast version just lets you learn it faster.

So pick something small. Let the AI break it. Save a copy first. Then fix one square and feel that little click of progress. That feeling is the engine. Protect it and you'll outlast every dumb tool and every bad night.

I kept stacking copies and moving programs onto the NAS, one at a time. And then one day the phone rang — a call that would change how I worked entirely. That's the next story.

This is part of From Zero to Ship — the honest logbook of a non-developer who shipped 20+ working tools with AI. If this resonated, the rest of the series is there.

#10 The Week I Held My Breath: Moving to a Real Server

FromZeroToShip — Fri, 10 Jul 2026 12:04:00 +0000

I had decided to move my tool to a real server. The only problem was I had no idea where to begin.

My tools all ran on spreadsheets back then. They worked, but one of them — a search tool I built to find supplies in our hospital storeroom — had gotten painfully slow. So I asked Gemini how to put it on our office NAS instead. (A NAS is just a storage box that sits in the building and serves files to everyone on the network.)

The answer was a long list. Settings to configure, things to move, permissions to set. And to do any of it, I needed the admin account.

I had never even seen that account. I worked in a therapy room. Admin access to the machine the whole hospital relied on was about as far from my world as it could get.

There was only one way forward. Go ask for it.

Asking for the keys

I went to the manager in the planning office.

I told him my tool was too slow, that I wanted to try moving it to the NAS, and that I'd need the admin login and password to do it. Looking back, it was a bold thing to ask. A therapy-room employee, requesting the master key to equipment the entire hospital used.

He hesitated. He had good reason to.

Years earlier, that same NAS had been attacked. Someone broke in from outside, locked the whole thing, and demanded money or the files would be gone for good. In the end, the hospital paid to get its data back. After living through that, of course he was nervous about someone wanting to put more stuff on it. What if it gets attacked again?

So I told him this: I'd build it to run only inside the hospital, only for staff. If we never opened a door to the outside world, there'd be nothing for an attacker to come through.

I'll be honest — that was a reckless thing to promise. Back then I barely understood security at all. But it happened to be true in that moment, and he handed over the account.

A week of bracing for the worst

What followed was a week of pure tension.

I'd been told the old attack probably got in because the admin account had been left logged in. So every time I touched that account, my nerves were on edge. What if I press the wrong thing and erase the records of the entire hospital? When I finished for the day, I checked two or three times that I'd actually logged out.

It felt like a stranger fumbling around inside someone else's home — and not just any home, one that had already been burgled once.

The work crawled. I followed Gemini one line at a time. Configure this. Move that. When it broke, ask again. Solve one thing and the next wall appeared. I clung to it like that for a week.

The moment it worked

A week later, the moment came to open the tool for the first time on the new server.

I took a breath and ran it.

The screen came up. Not just came up — it snapped open, instantly. I typed a search. The tool that used to make me wait and wait spat out the result the second I pressed enter. Out of hundreds of thousands of supply items, the one I wanted appeared right away, like a trick.

It was absurdly fast.

I sat there staring at the screen for a while. A week of clenched nerves let go all at once. It worked. It actually worked.

The math that broke something open

Something opened up in me that day.

There was one more worry I'd carried in. Our NAS held five terabytes total, and every employee used it for photos and documents. I figured my tool would eat up space and crowd everyone else.

It turned out to be nothing. Data made of text barely takes up room. All those hundreds of thousands of supply records, added together, came to less than one megabyte. Lighter than a single photo.

Faster on the server. Safe because it stayed inside the building. And it took almost no space. Once I had confirmed those three things with my own eyes, the next thought followed on its own.

Then I could just move everything I've built over here.

If there's one thing I'd hand to you from that week, it's this: proving something works once, in the smallest possible version, is what gives you permission to think bigger. I didn't need a plan for all twenty tools. I needed one tool, on one server, working.

Every program I'd been running on spreadsheets suddenly had a way up to the next level. That one small win — moving a single tool — turned out to be the starting line for everything that came after.

Of course, back then I didn't yet know that moving the rest wouldn't be nearly as easy as I imagined. But that's the next story.

This is part of From Zero to Ship — the honest logbook of a non-developer who shipped 20+ working tools with AI. If this resonated, the rest of the series is there.

#9 The Treasure Room That Was Too Slow: Outgrowing My Server

FromZeroToShip — Thu, 09 Jul 2026 12:07:00 +0000

The thing that shook the ground under me was an inventory count.

The hospital had been open for more than twenty years, and in all that time it had never done a proper inventory. No one had a real list of what the building actually held — how many of each thing, sitting where. When you're small, you get away with that. When you grow, you don't. If you don't know what you have and where, things quietly leak away. So the facilities team finally decided to do the first full count.

Here's the strange part: I already knew how to do this.

A skill from another life

My path into this work is a little odd. Before I came back to being a physical therapist, I spent about two years at a research institute. While I was there, I ran the entire institute's inventory count by myself. So I knew, in my body, how much labor it takes and how long it drags on.

Counting the objects is the easy part. The real work comes after. You group similar things together. You give every single item its own unique code. Then you organize everything around those codes, so it can actually be found again later. Skip that design step and all your counting just becomes a pile of numbers nobody can search.

That design was the job. When the facilities team asked for help, the roles split naturally. I'd build a form and send it down. Each department would survey their own shelves and drawers and fill it in. Then I'd attach codes, gather it all in one place, and turn it into something anyone — managers, related departments — could search whenever they needed. I called the tool EasyFS.

At first it ran beautifully.

Then the data piled up

Supplies turned out to be far more numerous than I'd guessed. Every department, every room, every drawer was packed with them. The count climbed into the hundreds of thousands.

And the more it climbed, the more visibly the tool slowed down. One search, and the screen would freeze for a long, awkward moment. The thing I'd built so people could find supplies fast was now making them wait.

It frustrated me, and worse, I couldn't tell why it was slow. At that point I knew nothing about what happens inside a program. I didn't even have the concept of "structure" in my head. I just assumed there had to be some faster way to build it, somewhere out there.

So I asked Gemini. Why is this so slow? How do I make it fast?

The answer became my first thread to pull. My tool was running on Apps Script — Google's scripting layer — which routes through Google's own servers. Going out to a distant server and back, every time, was always going to be slow.

One sentence that wouldn't sit still

That single fact rolled around in my head in a funny way.

It's slow because it goes through Google's servers. So... if I ran it on our own server, wouldn't it be fast?

Writing it now, it sounds obvious. Back then I didn't even know what a server was. All I had was a vague hunch that "ours" would be faster. So I sat down and asked myself a plain question: what servers do I actually know about?

The EMR server came to mind first — the system that holds the hospital's medical records. But that was off-limits. It holds patient data and it's wired tightly to outside agencies, the national insurance bodies and the rest. It is not a thing someone like me gets to poke at. One wrong move and the hospital stops.

Then something completely different surfaced.

The NAS.

That shared storage box — a NAS, the little network drive in the office where staff dump photos and documents to share. Everyone connects to it and uses it together. So, when you think about it... isn't that kind of a server too? And if it is, couldn't I put my program on it?

I had no confidence. I didn't even know whether it was a possible thing or an impossible thing. But a question, once it lands, never quite leaves — and the most useful move a beginner can make is to take a vague hunch seriously enough to test it, before you're sure it's allowed.

So I decided to move EasyFS onto that NAS.

What this really was

Looking back, that was the moment I stepped off the toy setups.

I didn't learn it from a course. I reasoned my way there from one offhand sentence an AI gave me, plus the only servers I happened to know existed. That's it. No background, no permission, no plan — just a slow tool and a question I couldn't drop.

The hunch turned out to be right, but the road there was longer and stranger than I expected. Moving a program onto a box meant for storing photos opened up a whole set of problems I didn't know existed yet. That's the next story.

This is part of From Zero to Ship — the honest logbook of a non-developer who shipped 20+ working tools with AI. If this resonated, the rest of the series is there.