I Started Building Again — Here's What Actually Happened

gitback2life documents real software work, practical learning, and problem-solving in public. This is not a polished overnight-success story; it is an honest account of what has been built, what went wrong, and what the work has taught me.

Published on the gitback2life project site · October 8, 2026

This started with a simple idea

I'm disabled and live with complicated health issues. For a long time, those realities limited the work and projects I could take on. Some of those complications affect my memory and make it difficult to stay focused on a task.

That's one reason I chose AI as a tool: it can help me organize ideas, break work into manageable steps, and regain context when I lose my place. I still make the decisions and verify the results; AI helps me work through the steps.

I'm now putting my energy into learning, building useful things, and solving real problems. I didn't begin with a giant master plan. I had a computer, curiosity, access to AI, and a willingness to learn by doing.

That became gitback2life.

The name is intentional, but it isn't a label for me. It points to what I'm doing now: learning in public, making things, solving problems, and building a future with more options. Modern technology is one tool for that work.

AI helped. It did not make the hard parts disappear.

One of the first things I learned was that having AI available is not the same as having everything figured out.

AI can generate code, explain unfamiliar ideas, suggest fixes, research questions, and help turn an idea into something tangible. But someone still has to notice when the result is wrong, decide what matters, test it, understand the failure, and keep going.

That distinction became part of the project's identity:

The first real project was already there

I was not starting with an empty computer and no code. I already had an AI-assisted Windows task-management application.

That turned out to be important. Instead of only talking about learning programming, I could work on something real.

The task manager became the first major case study for the project: code changed, bugs appeared, behavior had to be investigated, and the difference between “the program says it worked” and “the user can actually see that it worked” became very real.

Then gitback2life itself started having problems

The first visual direction was too bland. It didn't feel like the story, so it got thrown out and rebuilt into the cyber-tech mountain-and-sunrise identity that exists now.

Getting the public repository and GitHub Pages site running was not one clean automated step either. Platform limits, configuration, and privacy details all had to be worked through.

At one point, a commit exposed an email address in Git history that did not fit the project's privacy model. That got caught during verification, and the commit setup was corrected for future work.

Then I built a thing before fully understanding why I needed the thing

More recently, I built an Opportunity Tracker. The idea was to have a small local tool for recording real opportunities, deadlines, source links, evidence, notes, risk, and status.

It works. I tested saving, refreshing, importing JSON, exporting JSON, and the various confirmation states.

And then I asked the obvious question:

That was a good question because the answer exposed a missing piece. The tracker does not create opportunities. It is a filing and follow-up tool for real opportunities found somewhere else.

In other words, I had built part of a workflow before the whole workflow was clearly defined.

Then came the scientific JSON experiment

I created a random file containing:

and tried to import it as JSON.

It failed. Correctly.

A file being named .json does not magically make the contents JSON.

That small experiment led to another improvement: the importer now distinguishes between invalid JSON and valid JSON that simply does not contain an opportunity record.

Even “it saved successfully” turned into a lesson

The save operation was working, but the confirmation message was so visually quiet that I had to hunt for it.

So that got fixed too.

The lesson was bigger than the button:

Why keep the mistakes?

Because the mistakes show that this is real work, not a polished overnight-success story. The record is about decisions, experiments, corrections, and the things the evidence actually supports.

I am not documenting a version of this where AI did everything for me and every first answer was perfect. That wouldn't be honest, and it wouldn't be very useful.

The useful record is the messy one:

What gitback2life is actually trying to do

This project is bigger than a job board and bigger than a collection of little web pages.

It is a practical effort to build skills, useful software, and more options through learning, software development, problem-solving, and persistence. AI is one tool in that work; it does not replace the human decisions or verification.

Sometimes that means writing code. Sometimes it means figuring out a platform. Sometimes it means admitting that a feature was not actually solving the right problem. Sometimes it means making a tiny test file full of nonsense just to see what happens.

All of it counts when it produces understanding and forward movement.

So this is the beginning

The website is live. The repository is public. The first software case study exists. New tools have been built and tested. The project has a record of mistakes, corrections, and lessons.

There is still a long way to go.

That is the point.

Building what comes next, one line of code at a time.