Wednesday, 9 September 2026

BreadFlow: A Simple Way to Plan, Bake and Track Bread

BreadFlow logo

I've been getting into bread making recently. I'm still a total noob, but one thing I've already realised is that bread is as much science as it is cooking.

There are recipes to tweak, hydration levels to think about, kneading and proofing schedules to experiment with, baking temperatures to adjust, and then the question of whether the final loaf was actually any good.

Naturally, I wanted an app for that.

Introducing BreadFlow

BreadFlow is a small app for creating, organising and tracking bread-making workflows.

The basic idea is that a bread is made up of three separate components:

  • Recipe — ingredients, quantities, hydration and other recipe details
  • Proofing / kneading schedule — the sequence of rests, kneads, fridge periods and other tasks
  • Baking profile — temperatures, timings, covered/uncovered baking and cooling periods

You can create your own components or start with the built-in ones.

Once you've chosen a recipe, schedule and baking profile, you combine them into a Bread.

That Bread can then be executed as many times as you like.

Actually Making the Bread

Starting an execution gives you a simple step-by-step task list to work through while you're making the loaf.

You can check tasks off as you complete them, record comments along the way, and BreadFlow keeps track of the timings.

One feature I've already found particularly useful is recipe scaling. When starting an execution, you can specify how much total dough you want to make and BreadFlow automatically scales the ingredient quantities for you.

Once the bread is finished, there's a short survey where you can rate things such as the crust, crumb, flavour and rise, along with any notes you want to remember for next time.

Over multiple attempts, this gives you a record of what you made, how you made it, and how well it turned out.

Deliberately Simple

I wanted BreadFlow to stay simple, so it's a single-page application built with React and Vite.

There is no backend and BreadFlow doesn't store your data on a server.

Everything is stored locally in your browser.

That does mean that clearing your browser data can also remove your recipes, breads and execution history, so the app includes options to export your data to a file for backup.

You can also export and share breads with other people.

An App of Necessity

As usual, this is an app of necessity.

Sure, I could probably keep track of all of this with a notebook and a pen — assuming I was both able and willing to keep a sensible notebook.

But building something to do it for me seemed much more appealing.

If anyone else finds it useful too, that would be even better.

BreadFlow is available now at:

https://breadflow.isnow.online/

I hope you enjoy it.

Monday, 31 August 2026

Migrating isnow.online to AWS

This weekend, isnow.online and its subsites were migrated from Cloudflare to a fully AWS-hosted setup.

The main goal wasn't simply to move hosting providers. This was also an opportunity to get more hands-on experience with AWS, Terraform, Infrastructure as Code (IaC), CI/CD and DevOps practices while putting some better foundations in place for future projects.

Building it with Terraform

As part of the migration, I created reusable Terraform modules covering the two main hosting patterns currently needed:

  • Static site hosting — static sites and SPAs are stored in S3, with CloudFront providing the public-facing frontend.
  • Lambda-based sites — applications such as Lyricle and Birdle, which need a small amount of backend functionality, use AWS Lambda with public Function URLs.

Building these was a useful Terraform learning exercise, particularly around module creation and reuse. I also settled on a project topology and approach to managing multiple environments that works well for how I want to operate these projects.

Some AWS standards

I've also started defining AWS policies and standards for the wider isnow project, primarily around resource naming and tagging.

They're fairly simple at the moment, but having these conventions defined early should make the AWS environment much easier to manage as more applications and infrastructure are added.

Staging first, then production

Before touching the live site, the new infrastructure was deployed into a staging environment so the complete setup could be tested.

Once I was happy with that, migrating production took barely an hour. Having the infrastructure already defined and tested through Terraform made the production deployment considerably simpler.

I've also updated the local development server so it uses the same backend code that is eventually uploaded to the Lambda functions. This should keep local development and AWS deployments consistent and reduce the chance of deployment-specific failures.

Next up: CI/CD

All of the projects are now in GitHub, and with the Terraform configuration there too, the next goal is to turn the current setup into a proper CI/CD stack.

There are plenty more infrastructure updates and new applications I'd like to build, but this is primarily a casual project and a way for me to gain more practical experience with AWS, Terraform, CI/CD and DevOps.

So, there's no particular timeline for what comes next.

For now, go check out the newly AWS-powered isnow.online:

https://isnow.online