Tweed Tyne is a small company, and AperioFlow is a live product that we run our own work on. That is the simplest description of this post. The earlier post on building AperioFlow in public covered why we build it openly. This one is about the day-to-day: what sits in tasks, what watches our sites, and where the tool still gets in the way.
Who we are: a small company with a live product
We are a small team. Most of us wear more than one hat, and the same few people get the message when something breaks. That is the situation AperioFlow was built for, so it makes sense to test it on our own work before we ask anyone else to rely on it.
AperioFlow is running in production. Customers sign in, plans are on the pricing page, and the product is run from the UK and hosted in France. We do not describe it as more mature than it is. It is a focused tool doing a small set of jobs: planning work, catching errors, watching uptime and telling people when something goes wrong.
The practical effect is that when we talk about a feature here, we have used it. When we have not, we say so.
What we track in tasks
We keep work in tasks, and we try to keep each task small enough that someone can finish it or hand it back in a day or two. A task that has been open for weeks is usually a task that needs splitting, not a task that needs another reminder.
We write the task so that a person who did not create it can act on it. That means a clear name, what done looks like, and the place where the problem showed up. If a task came from an alert, the alert goes in the description, not a memory of it.
We also try to keep the list honest. Work that is waiting on a client, a supplier or a decision is marked that way, so the open list shows what we can move today rather than what we hope to do someday.
Which monitors and heartbeats we keep running
The free plan includes 10 monitors, and that is a sensible place to start for a small team. Our rule is simple: a monitor earns its place when someone would want to know about the thing it watches before a customer tells them.
For websites, that usually means the public pages people arrive on and the sign-in path, checked from outside. Checking only the homepage tells you the server is up. It does not tell you that a customer can log in.
Heartbeat monitors are for the work that runs without anyone watching it. A cron job or a backup that quietly stops is easy to miss, because nothing on the screen goes red. A heartbeat works the other way round: the job sends a signal when it finishes, and if the signal does not arrive on time, the silence is the alert. We use heartbeats for jobs that would be painful to discover missing a week later.
What we alert on is as important as what we watch. An alert that fires for every small blip teaches people to ignore alerts. We keep alerts for conditions that need a person to act, and we send alert emails only to people in our organisation.
What we have changed because we use it ourselves
Running our own work on the product has changed how we set things up. The changes are small, and most of them come from noticing friction in our own routine rather than from a grand plan.
We review the monitor list on a regular schedule, because sites change and a check that made sense last year may now point at a page nobody uses. We also write incident updates in the same plain style each time, so a customer reading one knows what happened, what we are doing and when the next update will come. The discipline of writing for our own team first has made the customer-facing wording clearer too.
We have also learned to keep the number of people who can act on an alert small and named. When everyone is responsible, nobody moves. Assigning a clear owner for each monitor is a habit that has held up better than any setting.
We would rather describe these as habits than as results. We have not measured them against a baseline, and we are not going to put figures on them here.
What does not work yet, said plainly
No tool suits every team, and AperioFlow is no exception. It is a small product made by a small company, so it does fewer things than the larger tools in this space, and some parts are simpler than you may want. Where a gap affects how we work, we would rather say so than hide it.
We also do not want to list every gap here from memory. Anything we say is missing should match what the pricing page and the documentation show today, and we check against those before we write about a limit. If you need a specific feature before you commit, the honest route is to read the docs and try the free plan yourself.
What we are not claiming
We are not claiming that running our own work on AperioFlow makes us better at it, that the product will catch every problem, or that it will prevent outages. Monitoring tells you when something has gone wrong. It does not fix the cause, and it does not replace a person who understands the system.
We are also not making claims about security or compliance in this post. On data, what we can say is that AperioFlow is hosted in France, run from the UK, and that you can download your data. Anything beyond that belongs in the documentation, and we would rather you read it there than take our word for it here.
If you want to see how a small team can set up its own work this way, you can try the same setup. Start free at https://app.aperioflow.co.uk/#/signup and add your first monitors and tasks. Compare what you see with what we have described here, and keep what helps.