Day 100

Day 100 - August 9, 2026: The Challenge Succeeded Differently

A final reflection on 100 days of building, learning, publishing, and discovering that the most valuable outcome was not the original output.

One hundred days ago, I thought this project was going to be about dashboards.

The idea was straightforward: build 100 dashboards in 100 days, strengthen my data analytics background, and publish the process as I went. I expected to spend most of the challenge thinking about datasets, visualizations, and the questions a useful dashboard should answer.

That is not what happened.

Within roughly the first week, I found myself much more interested in all the technical threads behind building and publishing something. Even Day 1 did not produce a new dashboard. It went into DNS, routing, CI, formatting, security scanning, and making the development environment reliable. At the time, that felt like foundation work before the real challenge began.

Looking back from Day 100, it was the real challenge beginning.

I did not build 100 dashboards. If the challenge is judged strictly by that original output, I did not accomplish the goal I announced. I do not want to rewrite the premise after the fact or pretend that every repository, website, or infrastructure experiment was secretly a dashboard.

But if I judge these 100 days by their outcomes, the challenge succeeded far beyond what I expected. I consistently built, experimented, learned, published, debugged, secured, governed, and became more technically capable. That change had real consequences, including helping me reach a new role that I am tremendously enjoying.

The challenge succeeded differently.

The First Detour Became The Path

Before this project, I owned a domain but had never done very much with it. During these 100 days, domains went from being vague future possibilities to things I understood how to operate.

I created and deployed my own portfolio site. I adapted the same foundation into a portfolio site for my wife. I kept this blog running. I built a placeholder platform so the many other domains I had acquired would show an intentional page rather than nothing at all. By Day 16, the documented inventory had reached 71 domains, each part of a managed surface rather than merely a name in a registrar account.

That forced me to learn the system around a website: repositories, DNS, Cloudflare, hosting, deployments, redirects, certificates, email routing, security posture, and the difference between getting a page online once and operating it consistently.

I genuinely enjoy knowing that when I have an idea, I may already own a fitting domain where it can grow. There is something motivating about turning an idea into a place with a name.

There is also an operational and financial reality behind that feeling. Seven or eight months from now, renewal decisions will begin arriving. I will need to decide which domains still represent real possibilities and which were useful mainly as experiments. I will probably reduce the number.

That is part of the lesson too. Creating something is not the end of its cost. Every domain, application, dependency tree, deployment, and repository creates an ongoing claim on money or attention, and often both.

Terraform Opened An Unexpected Door

Once the domain collection became large enough, another question appeared: how could I manage it consistently and securely?

That question pulled me toward Terraform and infrastructure as code. What began as exploration around domain configuration became practical experience with inventory, repeatability, validation, security settings, provider constraints, and the boundary between what should be automated and what should remain under deliberate human control.

That thread created an opportunity I could not have predicted. The Terraform work directly contributed to getting an interview for an infrastructure-related position. I was not the right fit for that particular role because the team was looking for someone more senior, but it was still a very positive experience. It may also have created a relationship that matters for another position in the future.

More importantly, the interview probably would not have happened without real work to discuss. I did not begin the challenge with a plan to use domain governance as interview preparation. I followed a practical problem until it became a project, and the project made a new conversation possible.

That pattern repeated throughout the 100 days. One experiment led to another. Publishing led to infrastructure. Infrastructure led to Terraform. AI-assisted coding led to questions about tests and agent permissions. Those questions led to repository governance, CI/CD, security, and architecture decisions.

Curiosity produced connections that a more rigid plan might have missed.

Public Evidence Changed The Career Conversation

I believe this blog and the portfolio projects also helped me land my current role.

I want to be careful about that claim. I had prior experience with people at the company where I was rehired, and these projects were certainly not the only reason I received the opportunity. Hiring decisions are rarely explained by a single input.

This time, however, I had far more tangible things to discuss. I had public development projects, deployed portfolio sites, a blog documenting consistent technical work, and repositories showing how I approached engineering. I had examples involving AI-assisted development, testing, security, infrastructure, GitHub workflows, and the inevitable debugging required to make all of those pieces work together. I also had concrete work I could share and discuss on LinkedIn.

Instead of only saying that I was learning, I could point to evidence of the learning. Instead of saying that I enjoyed building, I could show things I had built and explain the decisions behind them.

My reflection is that this body of work likely helped. Whatever its exact share of the outcome, it gave me better conversations and a clearer account of how I think. I am grateful that those conversations helped lead me to work I now enjoy tremendously.

My Model Of AI Changed

At the beginning of the challenge, I was probably too optimistic about what AI-assisted development would look like. The speed was so striking that it was easy to imagine the main skill was asking for a large result and letting the model produce it.

One hundred days later, I still believe AI can increase my velocity dramatically. I also believe that velocity makes engineering discipline more important, not less.

My role increasingly feels like that of a conductor. I define the objective, provide constraints, establish repository rules, separate work into reviewable tasks, require tests, inspect the result, run validation, use CI/CD, include security checks in the normal workflow, and send the agent back when the evidence does not support what it claims.

Day 45 described this as moving from vibe coding toward harness engineering. That distinction became more concrete with every later project. An agent can generate an impressive amount of code quickly. It can also misunderstand a boundary, update too much, miss a repository convention, write a weak test, or confidently describe a result that the actual diff does not support.

For anything I care about maintaining, I strongly prefer a governed, test-driven workflow. The objective is not to make AI slow. It is to make its speed useful.

The Google and Kaggle AI Agents learning program reinforced that shift. I thoroughly enjoyed the coursework and labs, particularly the way they connected agents to specifications, evaluation, security, deployment, and human review. They helped clarify the difference between prompting a model to produce something and designing a lifecycle in which agents can operate safely and reliably.

AI remains the reason I can explore at this pace. I am simply much less naive now about what sits between fast generation and trustworthy software.

Governance Became An Accelerator

Some of the most important work during the challenge happened around the code rather than inside it.

Projects such as Lingua and Boo-Boo Story gave me room to experiment with repository-level AI instructions, tests-first and tests-separated workflows, pull requests, branch rules, CI validation, dependency management, security scanning, architecture decision records, agent permissions, review loops, integrations, and notifications.

At first glance, those controls can look like overhead. They add files, checks, rules, and moments when a change cannot proceed immediately.

My experience increasingly became the opposite. Once a repository stated what an agent could modify, what evidence a change needed, and where a human decision remained necessary, I could delegate work with much more confidence. Tests and CI caught drift. ADRs preserved reasoning. Branch and pull-request rules made the integration boundary explicit. Security checks made quality and risk part of the normal process rather than a cleanup activity reserved for later.

Good governance reduced uncertainty. That made it an accelerator.

It also had to remain proportional. Day 98 was partly about loosening rules that created friction without protecting an important boundary. Governance is not a contest to accumulate the largest number of blockers. A useful control protects something that matters, operates at the right point in the workflow, and produces evidence people can act on.

With those rails in place, repositories became more polished in weeks than they might have become through months of sporadic manual work. The agent could move quickly because the system made acceptable work easier to distinguish from merely plausible work.

One Experiment Kept Leading To Another

The challenge also gave me permission to explore adjacent areas without needing each one to become the new permanent focus.

I looked into Microsoft Founders resources, Microsoft Fabric, databases, and certification preparation. I experimented with Google NotebookLM and notebook-style research while considering approaches for a Thai dictionary project. I learned more about CI/CD pipelines, GitHub configuration, branch security, Teams integrations, and AI-agent workflows. I pursued Fabric- and database-related training so additional certifications remain an option.

The list itself is not the point. The useful part was the motion between the items. A question about a language project led to research tooling. A deployment problem led to CI. A security alert led to dependency graphs. A frustrating agent result led to better instructions and tests. A repository rule led to a larger question about where governance belongs.

The challenge became less like a syllabus and more like following a network of technical threads. I did not master every topic I touched. I did become better at entering an unfamiliar area, asking more precise questions, producing an artifact, and leaving behind enough documentation and evidence to continue later.

Building Is Easier Than Maintaining

One problem remains notably unresolved: technical debt at scale.

The final weeks made that problem difficult to ignore. Security alerts, dependency upgrades, Dependabot pull requests, failing checks, package changes, and repository maintenance are manageable when only a few applications are active. They become a different operating problem across many repositories.

AI dramatically lowers the cost of starting another project. It does not eliminate the cost of understanding, securing, updating, and operating that project afterward.

That leaves me with a question I expect to keep thinking about:

What happens when creating software becomes much easier than maintaining software?

If I eventually turn a dozen or two dozen of these domains into real applications, maintenance could become the bottleneck. Every application would bring another dependency graph, CI pipeline, security surface, release process, and set of assumptions that can grow stale.

Perhaps that problem will bring the challenge full circle. If I return to the original dashboard idea, one of the first dashboards I now want to build would provide an operational view across my repositories: security vulnerabilities, Dependabot activity, failing CI checks, stale dependencies, repositories that need attention, and technical-debt trends over time.

The attempt to build dashboards led into software engineering and infrastructure. That exploration may have created the need for a dashboard I would genuinely use.

One Hundred Small Days Compounded

Not every day felt important while I was living it.

Some days were dependency problems. Some were a failing CI job, a security alert, a small UI adjustment, an added test, an ADR, a branch rule, a research session, or a correction to something an AI agent produced incorrectly. Day 99 was mostly security maintenance across existing repositories. There was no dramatic launch waiting at the end of it.

Individually, many of those days would not qualify as transformational. One hundred of them compounded.

My technical environment is different from the one I had on Day 1. My portfolio is different. My Git and GitHub habits are different. My confidence in working through unfamiliar systems is different. Most of all, my understanding of modern AI-assisted development is substantially different.

The transformation did not come from one breakthrough project. It came from returning almost every day and doing something programmatic and constructive, even when the day’s work was maintenance rather than invention.

That consistency also changed how I spent my time. Before the challenge, some of these hours might have quietly disappeared into streaming services or other passive entertainment. There is nothing wrong with that. I still enjoy it. But for these 100 days, I had a reason to choose building or learning a little more often.

Those choices accumulated into something meaningful.

Output And Outcome

The original output was 100 dashboards. I did not produce it.

The outcomes were public projects, deployed sites, portfolio work, infrastructure and Terraform experience, stronger Git and GitHub practices, better CI/CD knowledge, more security awareness, better testing habits, repository governance, certification and training exposure, interview opportunities, a new job, and a much more realistic understanding of AI-assisted engineering.

More important than any inventory, I built a habit. For 100 days, I kept finding something worth learning, improving, documenting, or maintaining.

That is why I can be honest about missing the original output and still regard the challenge as enormously successful. The goal changed because I learned enough to discover a more interesting set of questions.

What Comes Next

I am not announcing a Day 101 project.

I can imagine another 100-day challenge in the future. I might return to the original premise and deliberately build dashboards. I might spend 100 days going deeply into Terraform and infrastructure. I might choose several domains and turn them into genuinely high-quality applications. I might focus narrowly on one technical skill, or build the tools that make this growing collection of projects sustainable.

The next challenge should probably be more intentional and more carefully scoped because of what this one taught me.

It should also preserve some openness. One of the best outcomes of these 100 days came from letting myself pull on interesting threads instead of rigidly forcing every day back into the original plan.

On Day 1, I thought the infrastructure work was preparation for the dashboard challenge. On Day 100, I can see that learning how to build, publish, secure, govern, and maintain things was the challenge I actually needed.

I am proud that I finished the 100 days. I am grateful for where they led, and I am aware of how much I still have to learn.

For now, that is enough of an ending—and enough of a beginning.

Definition Of Done

Day 100 completed the first 100 Day Dash: