How I label project status honestly in my developer portfolio.

Status is part of the project evidence

A screenshot, repository, or technology list does not tell a reader whether a project is operating publicly, still being developed, or preserved as coursework. I treat status as a required part of the project description because it changes how every other claim should be understood.

Clear labels do not make a portfolio weaker. They give a recruiter, client, or collaborator the context needed to evaluate the work fairly. That is more useful than presenting every project as if it had the same maturity, audience, and operational history.

Live means I can verify the public destination

I use Live when a public URL resolves, the current page can be inspected, and the portfolio description matches what the visitor will actually see. My Il Veliero Porticello client website, the Greater Expectation community-service website, and Redeemed by Casper all have public destinations that readers can visit.

Live does not automatically mean that I claim traffic, revenue, rankings, bookings, or business results. Those are separate outcomes that require separate evidence. The status label confirms availability, not an invented measure of success.

In Development makes unfinished work understandable

I use In Development when a project has a real purpose and active work behind it but should not be read as a finished production release. The Isaac Wright Jr. Advocacy Website is labeled this way. The project is being developed with his knowledge and approval, but I do not call it official or describe it as complete.

This label lets me discuss planning, content architecture, and implementation without hiding the current boundary. It also gives me a clear maintenance responsibility: when the status materially changes, the project page, portfolio summary, resume references, and links must be reviewed together.

Coursework identifies the learning context

Coursework is not a disclaimer that erases technical work. It explains the setting in which the work was completed. Jukebox Pro demonstrates API authentication, user-owned playlists, PostgreSQL data modeling, and automated tests. Book Buddy demonstrates a React client working with an external API. Both remain useful evidence when their learning context is stated accurately.

I avoid implying that a classroom repository is a commercial production system. Instead, I describe the workflow, technical decisions, repository, and lessons that a reader can verify. The result is still strong because the claim matches the evidence.

Prototype describes a tested idea, not a launched product

I use Prototype when an application explores an interaction or product idea without a verified public deployment. Sturgis Options is a prototype that explores rental comparison, filtering, lightbox viewing, voting, and comments. Its repository and screenshots can show the concept without suggesting that it is an active rental marketplace.

A prototype can prove planning and implementation ability. What it cannot prove by itself is production reliability, adoption, or business performance. Keeping that distinction visible makes the technical story more credible.

The label and the supporting links must agree

I check each project against the same basic evidence: purpose, current status, public URL, repository, screenshot, technology, limitations, and the specific work I completed. A live label should lead to a working live page. An in-development label should not be surrounded by launch language. Coursework and prototype entries should not borrow production claims from unrelated projects.

This review also helps me decide where a project belongs. The recruiter resume can carry a concise status-aware summary. The full projects page can provide screenshots, links, and more context. A dedicated case study can explain decisions and lessons without changing the underlying status.

My practical status checklist

• Use one plain status label near the project name.
• Verify that the live URL or repository supports the description.
• Separate availability from unverified performance outcomes.
• State coursework and prototype context instead of hiding it.
• Use In Development for unfinished work and avoid official language without authorization.
• Update related portfolio and resume references when the status changes.

As a developer in Bergen County, New Jersey, I want people who find my work under Frank Smith III or the shorter Frank Smith name to see the same accurate project record. Consistency matters more than repeating a search phrase. The strongest signal is a portfolio whose labels, links, screenshots, and claims agree.