I Thought the Countdown Was the Product. The First Commit Changed My Mind.

I built DevMarathon around a simple belief:

Most developers do not need another project idea.

They need a structure that helps them finish one.

That belief came from my own experience.

I could start projects easily. AI made that even easier. I could generate ideas, compare stacks, create architecture plans, and produce a decent starting point in minutes.

But finishing was still difficult.

So I built a product around constraints.

A developer starts a 72-hour marathon, receives an AI-assisted build plan, gets a private repository created in their own GitHub account, and works toward a finished project before the countdown ends.

The idea was simple:

Less time creates less room for overthinking.

Then real users arrived, and I learned that the countdown was not the real beginning.

I also recorded a short demo of the current flow for anyone curious about how the marathon setup works: https://www.youtube.com/watch?v=-LyHdgPlz40

Clicking “Start” Is Not the Same as Starting

Some users created a marathon.

The countdown began.

Then they disappeared.

They did not complete the project.

Some did not return after the first session.

At first, I thought this was simply a completion problem.

Maybe the project scope was too large.

Maybe 72 hours was too short.

Maybe the users were not motivated enough.

But the more I looked at the journey, the more I realized I was measuring the wrong event.

I was treating “marathon created” as activation.

It was not activation.

It was intent.

Creating a marathon only means someone liked the idea enough to press a button.

It does not mean they have committed to doing the work.

The real beginning might be the first commit.

Or the first completed milestone.

Or returning to the project the next day.

Those actions require effort.

They show that the user has crossed the gap between being interested in building and actually building.

That distinction changed how I think about DevMarathon.

A Countdown Can Create Urgency, but It Cannot Create Commitment

I still believe constraints are useful.

A visible deadline forces decisions.

It makes scope feel real.

It reduces the temptation to rewrite everything before anything works.

But a countdown cannot rescue a project that never gains momentum.

If the user creates a marathon and then sees a large project plan, unfamiliar architecture, or too many decisions, the deadline may feel less like motivation and more like pressure.

That means the most important part of the product may not be the final evaluation.

It may not even be the 72-hour timer.

It may be the first hour.

Can the user understand the scope?

Can they open the repository?

Can they identify the first meaningful task?

Can they make visible progress before the initial excitement disappears?

I originally focused heavily on what happens at the end of the marathon.

Now I am paying much more attention to what happens immediately after it begins.

GitHub Taught Me That Technical Logic Is Not User Trust

GitHub is a core part of how DevMarathon works.

When a developer starts a solo marathon, DevMarathon creates a private repository inside their own GitHub account.

The repository contains the starting structure for the project.

The developer owns the repository and works from their own account throughout the marathon.

From a product perspective, GitHub access makes sense.

From a new user’s perspective, it creates a different question:

“Why should I give a platform I just discovered access to my GitHub account?”

That hesitation is reasonable.

Developers are constantly asked to authorize applications, install tools, and grant permissions. They have learned to be careful.

I initially treated GitHub authorization as a technical step.

Users treated it as a trust decision.

That is a much better description of what is happening.

Explaining that the repository is private is not enough.

The product must also explain:

• Why GitHub access is required
• Which permissions are requested
• What DevMarathon creates
• Where the code will live
• Who owns the repository
• What the platform can access
• How access can be removed later

The user should understand all of this before reaching the authorization screen.

To reduce the initial barrier, I added Google sign-in.

People can now enter the platform and explore it without immediately connecting GitHub.

GitHub is only required when they decide to start a real marathon and create the repository.

This does not remove the trust problem completely.

But it lets users understand the product before they are asked to connect an important account.

That feels like a much healthier order.

Value first.

Permission second.

The Metric I Care About Is Changing

A growing number of registered users can feel encouraging.

So can a dashboard full of created marathons.

But neither number tells me whether DevMarathon is helping someone build.

The metrics I care about now are closer to actual behavior:

• Did the user connect GitHub?
• Was the repository created successfully?
• Did they open or clone it?
• Did they make a first commit?
• Did they complete the first milestone?
• Did they return after the initial session?
• Did they submit something before the deadline?

These events tell a much clearer story.

A marathon creation is a promise.

A commit is evidence.

This is especially important because DevMarathon is ultimately about proof of execution.

The platform should not only say that someone started.

It should reveal how they progressed.

This Also Changed How I Think About Developer Evaluation

DevMarathon started as a solo product for developers who wanted structure, pressure, and a finish line.

It has since expanded into structured challenges for companies, schools, and developer communities.

Organizations can create a challenge, invite participants, and review the work produced during the process.

The original B2B idea was straightforward:

A CV tells you what someone claims to know.

An interview tells you how they communicate.

A completed project shows what they can produce.

I still believe that.

But observing the solo marathons added another layer.

The final project is not the only useful evidence.

The process matters too.

Did the participant begin quickly?

Did they make consistent progress?

Did the scope change?

Were important tradeoffs documented?

Did the setup instructions work?

Was the project tested or manually verified?

What was completed, and what was intentionally left out?

A single score cannot communicate all of that.

For hiring challenges, I am becoming more interested in creating a compact execution report that helps a human reviewer understand the work.

Not an AI system that declares who the best developer is.

A system that organizes the evidence so a company can ask better follow-up questions.

The AI-assisted evaluation can still be useful.

But the evidence behind the evaluation may be more valuable than the number itself.

What DevMarathon Is Becoming

The original idea was:

Give developers 72 hours and make finishing unavoidable.

The more honest version is:

Give developers a clear starting point, a realistic scope, visible pressure, and a reason to keep moving.

The product cannot force someone to finish.

It can reduce the number of places where momentum quietly dies.

For solo developers, that means helping them turn an idea into a real project and a shareable proof of execution.

For organizations, it means creating structured challenges where candidates can be reviewed through actual project work instead of relying only on CVs and interviews.

Both sides are connected by the same principle:

Execution should produce evidence.

What I Am Working on Next

The next phase is less about adding more features and more about improving the path from intent to action.

That includes:

• Making the GitHub permission flow easier to understand
• Showing the user what will happen before authorization
• Helping users choose a realistic 72-hour scope
• Making the first milestone smaller and clearer
• Improving reminders when momentum begins to drop
• Measuring first commits and milestone progress instead of only marathon creation
• Building richer execution reports for structured challenges

The goal is not to make the marathon easier.

The goal is to make the next action obvious.

There is an important difference between those two things.

The Lesson

I started with this belief:

People need constraints to finish.

I still believe it.

But now I would add something else:

Constraints only become useful after the user makes a meaningful first move.

A timer can create urgency.

A plan can create clarity.

AI can remove the blank page.

But the first real action still belongs to the builder.

For DevMarathon, that first action is increasingly looking like the first commit.

That is the moment the project stops being an intention and starts becoming evidence.

I am curious how other founders think about this:

What action inside your product tells you that a user has truly started?

Not registered.

Not clicked a button.

Actually started.