DEV Community: ArtisanJack (っ◔◡◔)っ

I built a verified launch registry for Laravel. Here's why.

ArtisanJack (っ◔◡◔)っ — Sat, 29 Aug 2026 15:01:55 +0000

Every launch directory I've ever used had the same problem: I couldn't tell which projects were still alive.

Product Hunt, GitHub trending, the dozens of "awesome lists" — they all have their place. But when I wanted to see what indie Laravel developers were actually shipping, I kept hitting the same wall: beautiful cards linking to apps that no longer exist. Directories rot because listing something dead costs nothing.

So I built Shipped — a launch registry for Laravel projects where every entry is verified to be actually running. It's free, and it lives at larashipped.laravel.cloud.

What it does

The idea is simple. You record your project, write a short release story, and point Shipped at your live *.laravel.cloud URL. Before anything goes public, Shipped checks that the app is genuinely up: it resolves DNS, probes the origin without credentials, refuses off-origin redirects, and matches the Cloud slug against the live hostname. If the check passes, you get a publishable launch page — and a "LIVE ON CLOUD" badge you can drop into your README.

Then verification doesn't stop. Shipped rechecks every launch daily. If your app goes down, your card goes private — automatically.

That last part is deliberate. A registry full of dead links is worse than no registry at all. I'd rather your launch page disappear than mislead someone.

What it doesn't do

It doesn't verify that you own the Cloud organization, and it doesn't score your code. URL-backed verification answers exactly one question honestly: "is this thing actually live right now?" That tradeoff is the product. (I wrote about the security details of that decision in a separate post.)

Why I care about this

Shipping side projects is lonely. Half the motivation dies in the gap between "deployed" and "anyone noticed." A verified registry gives launches a home people can trust, and gives the rest of us a reason to click.

What's next

Scheduled release notes, follows, and a private activity feed are already in the works — the roadmap is driven by early users, so they get heard first.

The ask

If you've shipped anything on Laravel Cloud — a SaaS, a tool, a weekend experiment — add your launch and grab the badge. It's open source, too: github.com/jvbalcita/shipped.

And if you haven't shipped on Cloud yet, I'd still love your take:

Would you trust a registry that rechecks launches daily and unpublishes dead ones? What would make you submit your own project — or what would stop you?

I stopped asking for Laravel Cloud API tokens

ArtisanJack (っ◔◡◔)っ — Fri, 21 Aug 2026 10:50:03 +0000

I originally verified LaraShipped launches with a Laravel Cloud API token.

Creators pasted a token. I stored it encrypted, never showed it again, and used it to inspect environments. On paper that proved the app lived in their Cloud account.

In practice, people didn't want to give me a token. I wouldn't either.

So I changed the contract.

What we check now

You paste an HTTPS *.laravel.cloud URL. That's it.

Then we:

resolve DNS and refuse anything that isn't a public address
probe the origin without cookies or credentials
refuse off-origin redirects (a / → /login on the same host counts as reachable; we don't follow it)
compare the Cloud slug against the project's live hostname, including custom domains

artisanbizops.com can match artisan-bizops-x1233.laravel.cloud after we strip separators from the first label. That's a consistency check, not proof that you own the Cloud org.

If the names don't match, we fail before the outbound probe. No point hitting the network for a URL that can't belong to this project.

A successful probe never publishes the project. You still have to hit publish.

A failed or stale daily recheck makes it private. We don't auto-republish later. Showcase lists go stale when a card stays pretty after the app dies. I'd rather the page disappear.

The probe is read-only. It doesn't trigger deploys, restart environments, or buffer an unbounded response. If HEAD comes back 405 or 501, we may fall back to a streamed GET, but the body is capped at 64KB and then closed.

What this is not

Someone could still point a *.laravel.cloud URL at an app that isn't theirs if they guessed a slug and the live hostname lined up. Token-backed verification was stronger on ownership. URL-backed verification is stronger on is this actually up, and on not holding a secret I don't need.

That tradeoff is the product. LaraShipped is a verified Laravel Cloud registry, not a general launch directory.

If you've shipped something on Cloud and you're tired of directories that never check, the door is open: larashipped.laravel.cloud

How to Track Coding Time Using GitHub Commits (Without Manual Timers)

ArtisanJack (っ◔◡◔)っ — Tue, 24 Feb 2026 01:06:34 +0000

Developers measure everything.

Performance metrics.

Test coverage.

CI pipelines.

Deployment frequency.

But one thing many developers still struggle with?

Accurately tracking coding time.

Whether you're a freelancer, consultant, or full-time engineer, understanding where your development hours go isn’t always straightforward.

Let’s talk about why.

The Problem With Traditional Developer Time Tracking

Most developer time tracking methods fall into one of these categories:

Manual timers
Timesheet spreadsheets
Calendar reconstruction
End-of-week estimation

The issue?

Development work doesn’t happen in clean, uninterrupted blocks.

You:

Switch branches
Review pull requests
Debug production issues
Fix “quick” bugs
Jump between repositories

By the end of the week, trying to answer:

“How many hours did this feature actually take?”

Becomes a memory exercise.

And memory is unreliable.

Why Manual Time Tracking Tools Often Fail Developers

Traditional time tracking tools assume this workflow:

Start timer → Work → Stop timer.

But real coding sessions look more like:

Slack interruption
Context switch
Emergency fix
Back to main feature
Small refactor
Another context switch

Developers forget to start timers.

Developers forget to stop timers.

Developers forget to switch tasks.

That’s not laziness — it’s how development naturally flows.

Manual developer time tracking requires discipline.

And discipline-based systems break under context switching.

What If GitHub Is the Source of Truth?

Every meaningful coding session leaves data behind:

Commit timestamps
Branch activity
Pull requests
Push frequency

Your GitHub activity already forms a timeline.

So instead of asking developers to manually track time…

What if we used commit activity to approximate coding time?

This is the idea behind GitHub time tracking using commits.

Not perfect precision.

But structured visibility.

Can You Track Coding Time Using Commits?

Let’s address the obvious question:

Are commits accurate enough to represent development time?

Not perfectly.

Some work happens before a commit.

Some commits are tiny.

Some long sessions produce few commits.

But commit-based tracking can still:

Reveal workload distribution
Show time spent per repository
Surface development patterns
Reduce end-of-week guesswork

It won’t give you second-by-second precision.

But it can dramatically improve clarity over pure estimation.

Exploring Commit-Based Developer Time Tracking

I started experimenting with a commit-based developer time tracking approach that:

Connects to GitHub
Pulls commit activity
Groups commits into time blocks
Generates a development timeline
Breaks down activity per repository

Instead of asking:

“How long did I work?”

You can start asking:

“What does my GitHub activity show about how I worked?”

For freelancers, this could support clearer billing transparency.

For full-time engineers, it can provide personal productivity insights.

Introducing LogBytes (Early Beta)

That exploration turned into a small SaaS project called LogBytes.

LogBytes connects to GitHub and generates a timeline view of your development activity so you can:

Track coding time using commit data
Visualize time distribution across repositories
Reduce manual timesheet effort
Improve developer time awareness

It’s currently in early beta while I refine the commit-based tracking model.

I’m not claiming it replaces human judgment.

I’m building it to reduce blind spots in developer time tracking.

I’d Love Your Feedback

If you’re a:

Freelance developer
Consultant
Agency engineer
Or someone who tracks billable hours

I’d genuinely love your perspective.

Would you trust GitHub-based time tracking?

What would make commit-based tracking reliable enough for billing?

You can check out LogBytes here:

👉 LOGBYTES