We Kept Building Until the Studio Became Software

The website was the easy part.

Not because websites are easy. A good one still asks for writing, design, engineering, and a willingness to remove things that once seemed essential. But the page is only the visible end of a much longer chain.

Someone sends an inquiry. A client reviews a direction. An article moves from a draft to publication. A photograph needs to reach one person without opening a folder to everyone. A product needs an honest price. A workshop needs to stop accepting reservations when the room is full.

Keep following those ordinary tasks and eventually the studio starts becoming software.

That is what has been happening at theProject. The public identity has become stronger, and the less visible machinery has had to become more deliberate alongside it. The aim is not to make a small practice look like a large institution. It is to make the work easier to manage without handing the complexity to the person on the other side.

The public site is a front room

Project Redefine is the public website. It presents the work, explains the services, introduces the studio, and gives visitors somewhere to read, browse, or make contact.

Its primary responsibility is orientation. A person should be able to understand what they are looking at and decide where to go next. The page should not expose a database record simply because the database contains one.

This matters as the site grows. Journal, Work, Services, Shop, and Events are different kinds of information. An essay needs a reading pace. A product needs an accurate choice. A workshop needs a date and a place. Making them visually related does not mean forcing them into identical boxes.

The shared identity comes from typography, spacing, imagery, and a consistent respect for the reader. The underlying information is allowed to keep its own shape.

Studio is where the records live

Behind the public website is Studio, the private working side of theProject. Its repository is called Nidhogg Protocol. Payload supplies the editing interface, and PostgreSQL stores the durable records.

Those names are useful to a developer. For everyone else, the purpose is straightforward: the studio needs somewhere to edit, publish, attach media, and keep track of things after a browser window closes.

A finished article should not require a code change whenever a paragraph improves. An inquiry should not vanish because an email notification failed. A registration should remain a registration when someone refreshes a page.

Putting these responsibilities in one backend does not mean every feature becomes one giant record. Articles, inquiries, client presentations, products, sessions, and transactions have different rules. Keeping those rules visible makes the software easier to maintain and its behavior easier to explain.

A message should survive its notification

Contact is a useful example because the interface looks so ordinary.

A visitor fills in a form and sends a message. The studio should receive it. That sounds like an email problem until an email fails.

The inquiry is therefore saved by Studio before a notification is attempted through Resend, the email service. Email is the alert. The saved inquiry is the record.

That order changes the failure case. If the alert does not arrive, the inquiry can still exist for the studio to review. The system can record the delivery problem instead of quietly losing the person's message.

This is infrastructure doing a very human job: respecting the effort somebody made to get in touch. The form does not need to explain the sequence. It needs to be backed by it.

A client presentation does not need to become a portal

Private client work needs a focused place to be seen and discussed. That does not automatically mean it needs a permanent customer dashboard.

Client Preview provides a protected presentation with the relevant work, context, and feedback choices. It is designed around the decision the client is making, rather than around all the account features a software product could theoretically have.

The distinction is practical. A client who needs to compare directions should not have to learn a navigation system full of unrelated features first. The presentation can give the work room to breathe and retain feedback in a form the studio can use later.

Privacy still requires serious machinery. Access is checked on the server. The private experience has its own handling for caching, search engines, and sensitive information. A quiet page is not evidence that there is no boundary. It is often the result of choosing the boundary carefully.

A photograph can have a lifecycle

The community-event delivery system began with another small task: let someone receive their photograph.

The resulting workflow connects private media, a delivery record, an opaque link, and a public presentation. The record can describe preparation, availability, and removal. The public page receives the information needed to show the photograph without receiving the storage credentials or a browsable folder.

The visitor does not need an account simply to complete the handoff. They can view, download, and decide whether to share the link. A removal request has a defined place in the process.

This feature belongs to a large local community event, but the broader lesson is not specific to that event. Small experiences still have states, responsibilities, and failure cases. Ignoring them does not make the experience simpler. It makes the failures harder to understand.

A publication and a notebook are different tools

Journal is the finished publication. Its articles are edited in Payload, with drafts, media, categories, and publication controls.

Field Notes and developer documentation remain local files alongside the public site's code. They are better suited to working observations, technical explanations, and references that evolve with an implementation.

Keeping the two separate helps the writing keep its purpose. A lab note can be valuable without pretending to be a finished feature. A considered essay can have an editorial life that is not tied to the next software commit.

The reader should feel the distinction in the experience, not be asked to understand the storage arrangement. Journal should feel like somewhere the studio has things worth saying. Field Notes should feel like an open notebook with useful pages marked.

The shop needs more than a buy button

The okayhacker apparel gives the Shop something tangible to show. The showcase image carries the actual identity across shirts and hoodies. It is a starting point for a release, not evidence of a particular stock count or delivery date.

The commerce foundation now separates product editing from payment handling. Studio owns the product, options, price, and internal order record. The public site presents those choices. Stripe hosts checkout and supplies the authoritative payment information.

This implementation is being introduced in test mode. It does not mean a live release has been stocked or that production checkout is already open. Those are operational steps requiring real product details, account configuration, and verification.

That distinction is part of the design. A convincing page should not be allowed to invent a working business process underneath itself.

Resale is a separate handoff

The Shop also has a place for listings from theProjectHoldings on eBay.

Those items belong to a different transaction system. The public site can present listing information and direct a visitor to eBay, but eBay remains responsible for that purchase. The listings do not become theProject's internal Stripe inventory just because they appear on the same page.

The integration uses the official API, a server connection that keeps application credentials out of the browser. If the credentials are absent or the service is unavailable, the site can still provide the seller link without inventing items.

This is a useful rule for integrations generally: know which part of the experience you own, and make the next handoff understandable.

A workshop is an idea plus a time

Events introduce a different distinction. A workshop describes what people will learn or make. A session describes when it happens.

Separating those records means the same class can run more than once without copying the entire description into a new hard-coded page. Each session can have its own date, price, capacity, and status.

Registration has to account for people checking out at the same time. A seat reservation is therefore a database decision, not a number adjusted in a visitor's browser. Pending reservations expire. Confirmed registrations remain durable. A free event uses the same capacity rules without sending someone through payment for a zero-dollar ticket.

The public page can stay close to an editorial schedule because the difficult bookkeeping happens elsewhere.

The confirmation page cannot decide what happened

A payment return page is an easy place to make a bad assumption. Someone arrived at the success address, so the transaction must have succeeded.

That address is not proof. Stripe sends a signed event to Studio, which verifies it and updates the durable record. The public page checks that state before describing an order or registration as confirmed.

Repeated notifications must also be safe. A payment provider can retry delivery. That should not create another order, consume another seat, or send another confirmation email.

These rules are not decorative precautions. They are what let a person close the tab, reopen the page, or encounter a slow network without turning a routine purchase into a mystery.

Infrastructure is part of design

The visible work still matters. A careful type scale, a strong photograph, and an intelligible page can change whether a visitor understands the offer at all.

But design also includes deciding what survives a failure, which information stays private, who is allowed to change a record, and what a confirmation actually means.

When that machinery is built well, the client barely notices it. Their message is there. Their feedback stays attached to the right work. Their photograph opens. Their reservation has a place in the schedule.

The studio became software one small responsibility at a time. The test of that software is whether it leaves more room for the people using it.