Version history, queued changes and live preview in the builder

Anyone who has built a product with a team of one knows the real cost of iteration. It is not the typing. It is the fear of breaking something that works, and the dead time spent watching a progress bar before you can say what you want next. Founders and freelancers building across time zones feel this more than most, because the person who could fix a mistake may be asleep.

A good builder should behave like a good document editor: you try something, go back if it is wrong, and keep working while the last change finishes. This release gives the builder those properties. Every build is kept as a version, changes you send while a build runs wait in line, and supported stacks run live while you edit.

Versions you can always go back to

Every build is saved as a complete, numbered version. The first generation is version one. Each change you request produces the next number, and so does each restore. Open Version history from the left bar and you see the list, with a short description of what produced each version. Restoring takes one click.

The detail that matters is that restoring is non-destructive. When you restore version four while you are on version nine, Afren does not delete versions five to nine and rewind. It builds a new version ten whose contents are version four. The record of how your app evolved stays intact, and if you restore the wrong one, the version you left is still there to return to. Source control systems work the same way, without asking you to learn what a branch is.

A few edge cases are worth knowing.

• Restoring the version you are already on is refused with a clear message, because it would change nothing.
• If a change fails, the failure is recorded against that change and your previous version is unchanged. You never end up holding a half-built app.
• If a build is interrupted before it finishes, that change is marked as not completed, your last good version is put back as current, and you can send the change again.
• A project keeps its most recent 30 versions. Older ones are removed as new ones are saved, which keeps the list usable and the storage bounded.

That last point is a trade-off. Keeping every version forever is simpler to describe, but a history of hundreds of near-identical builds is one nobody reads. We chose a window long enough to cover real experiments.

Changes that wait their turn

Send your next change while a build is running and it joins a queue for your project. The queue is first-in, first-out, the same rule as a line at a counter: changes are applied in the order you sent them. Only one build runs for a project at a time, so two requests can never race to overwrite each other.

You can see each waiting change and its position. You can cancel any change that has not started. Once a change is being built it cannot be cancelled, and the message says so plainly. Up to five changes can wait at once, and if you are at the limit you are asked to let some finish or cancel one.

One behaviour is worth explaining because it can surprise a careful user. Changes that sit next to each other in the queue can be applied together as a single update, and a restore always runs on its own. Applying three small instructions in one pass means fewer rebuilds, and the builder sees the whole list of what you want instead of one fragment at a time. The result is saved as one new version.

Why a queue and not parallel edits? Because two edits made at once to the same files have to be merged, and merging code correctly is much harder than ordering it. An ordered line trades a little waiting for a result you can rely on.

Live Preview on supported stacks

For supported stacks, your app now runs live in an isolated environment of its own while you work on it. Each change shows up within seconds, without waiting for a full rebuild. Select Live Preview to open it. The link is private to you, so the app is not exposed to anyone you did not choose, and it is temporary. Select Live Preview again whenever you want a fresh link.

Publishing is a separate act. A preview is a working surface for you. A published site is the permanent address you give to other people, and it updates only when you publish again.

Shortening the distance between "I want this changed" and "I can see it changed" is the single biggest lever on how fast you make good product decisions. Seconds invite experiments. Minutes invite you to batch your thoughts and lose them.

Smaller changes that remove friction

• Reopening a build. When you come back to a project you see its current build, or the one still in progress, instead of an empty screen. Close the tab in the middle of a build and the build carries on. Come back and you pick up where it stands.
• Clear publishing messages. When a publish cannot finish, the message names the reason: the build is not complete, the project needs a plan or a build credit, or something else you can act on. Publishing puts your app at its own address on an Afren demo address, and publishing again updates the same address, so links you have shared keep working. Plans are on the pricing page.
• A clearer About page. The About page now sets out who we are, when we were founded and how Afren works, in plain facts that are easy to check and quote.
• Better answers in Docs. The assistant on the Docs page now knows about publishing and every feature in the guide, so a question about how to do something gets a specific answer.

What this means for you

You can change your mind without cost, because every build is a version and every restore adds to the record instead of erasing it. You can keep thinking while the builder works, because your next change waits in an ordered line. And for supported stacks you see each change within seconds, which is how a rough idea turns into a decision.