A phone, a gym, a few seconds between two sets. That situation serves as TRAME’s specification, and it has undone several things we had built. TRAME is an internal OSOM Labs project: a training app built to measure for one person, in real use since summer 2026. It isn’t public, it can’t be downloaded, and this story gives no training advice. Fitness is simply the ground the example stands on. The question here is the one facing the management of an SME considering a custom business app: how to decide what goes into it, and when to walk away. What follows comes from our decision log and from measurements taken in the app’s database, mistakes included.
One sentence that settles arguments
TRAME’s project file opens on its use: at the gym, on a phone, between two sets, “the constraint that takes precedence over everything else”. That sentence translates into rules we can check.
Touch targets are at least 48 px. Each screen has one main button. A session opens only one exercise at a time. Anything read during a session is at least 13 px, and a test fails if a component goes below that.
The same file also says what stays out. One person uses the app: no roles, no invitations, no sharing, no subscription. Any feature that assumes a second user is out of scope.
In an organisation, the sentence will be different: a technician on a roof, wearing gloves; a receptionist with someone standing in front of them. If the team can’t write it, the project doesn’t have a subject yet.
Observe, then clear the way
In the first sessions we measured, the sets of an exercise were logged all at once, in a burst of 3 to 15 seconds, after the exercise was finished. So the app’s unit is the whole exercise, every set of it. The open exercise arrives already filled in, and “Done · 3 × 10 · 20 kg” logs all three sets in one tap. Set-by-set detail and the note stay optional and add nothing to the path. There is no rest timer: with logging done in a burst, it would serve no purpose.
The most instructive removal was the effort rating. Until 26 August, four small buttons were offered on every set: 0 entries across 38 sets. A simpler question replaced them, Easy, Just right or Hard, asked once per exercise. On 1 October, it had been answered for 20% of sets. From 14 to 26 October, for none at all, across five sessions. For the person using it, the question wasn’t intuitive.
On 26 October, the question left the screen. In its place, “Next time?” asks at the end of an exercise what to aim for: lighter, the same, one more rep, heavier. The old question looked backwards. The new one looks ahead, and its answer is used the next time that exercise comes up.
In a business app, a field nobody fills in is a measurement like any other. Either it costs too much at the moment it’s asked, or its answer serves no purpose. The database shows it, provided someone goes back and reads it.
Suggest, and leave the decision
The calculation in TRAME with the most riding on it concerns the next load. The rule is called double progression: reps first, and a heavier load only when four conditions are met. The last time the exercise was done, every planned set was completed. The weakest of those sets reached the top of the prescription, since a good first set proves nothing if the others fall away. Effort, when it was recorded, stayed under a ceiling. And the machine’s load increment is known. Not recording effort blocks nothing: otherwise the app would be punishing someone for not filling in a field.
Even with all four met, the result is a suggestion, never a change. The suggested load only enters the log if the person taps a button. The history knows the last time that exercise was done and nothing about how today is going. The person at the gym does.
One exception is on record. The target set with “Next time?” does prefill the next log on the same machine. The rule protects against a decision made by the app; this target is a decision made by the person, the last time that exercise was done. Automatic advice still fills in nothing.
The programme follows the same logic. It comes from outside: the app transcribes it and doesn’t rewrite it. A rep range closer to the app’s own habits was rejected, because it would have displayed something other than the prescription. When the programme’s machines had to be matched with those at the gym, three doubtful cases were settled one by one instead of being guessed from appearance: two were the same, the third wasn’t.
TRAME has no artificial intelligence feature. Its suggestions come from written rules that can be read and tested. The demonstration on our Labs page shows two of them with fictional data.
For any automation in a business app, three questions are worth asking: who decides, who can correct it, and what appears when the calculation doesn’t know?
When the app doesn’t know, it says so
Five machines added in September carried a default 2.5 kg increment that nobody had checked on the machine itself. The app could therefore suggest a step that didn’t exist. Those values were removed. An unknown increment now produces no numbered increase, until it has been checked at the gym.
Session durations went the same way. Sets logged afterwards, all at the same time of day, displayed “0 min”, and another session “3 h 48”. The summary now reads “Duration unknown · sets logged afterwards”, or “to be checked” beyond 2 h 30. “0 min” claimed a measurement that never took place. It’s the discipline we describe in the story of the honest algorithm.
Some figures mislead through their meaning. On assisted machines, the number shown is a counterweight: progress means bringing it down. Without that information recorded on the machine, the rule would have suggested raising it. Every trade has cases like this, and they are found on site.
The corrections that mattered came from the gym
On 1 October, an audit of the app went back over its real use. Since the visual redesign of 24 September, no session had been logged live at the gym. Two sessions had been opened then deleted without a single set, and sets entered afterwards. The notes and machine settings built around the session stood at zero.
The cause, as given by the person using the app: the app was offering the wrong session. A Friday session hadn’t been done. On Monday, the home screen still offered it, and its only button started nothing else. Monday’s session took place and couldn’t be logged at the time. Our logic kept the number of sessions done, never which ones. Since 29 September, the session offered has been the one after the last closed session, with “Do a different session” just below. A “Skip” button was rejected: it would have created a phantom session that the history and the calendar would have had to learn to ignore.
On 30 September, the start button took about 5 seconds to display the session. Measurement showed that the pages were running in Washington while the database is in Zurich. The database answered in 4 ms, the round trip brought that to 292 ms (medians over 131 requests), and a page chained 6 to 9 of them. Page computation moved to Frankfurt and the reads were grouped together. The gain from that move remains a deduction: we have no comparable measurement taken afterwards.
These two findings changed the order of work. Visual work was next on the plan. It moved behind the reliability of the session: keep the entry when the connection drops, show the wait, one open session at a time, no more deleting with a single tap. Three features already decided were made conditional on two weeks of sessions logged live. Our log puts it this way: “The finish can wait a week; a lost session can’t.” Since then, sessions have been logged at the gym again.
Other faults could only be seen on site. Until 26 August, the header was painted under the phone’s clock, and the “Finish” button sat in the strip where iOS intercepts touches. None of this appears on a development computer. A session from 24 August stayed open, with its 19 sets: the gesture for closing it looked exactly like a nearby link at the time. It was moved, and it now takes two steps.
What we check, and what tests don’t reach
As of 3 November 2026, the suite has 286 automated tests, and all 286 pass. They cover first the rules that produce a figure: the load increase, inverted loads, next time’s target, the length of a session, the date of a day in Swiss time. Nobody recalculates those figures at the gym: if they’re wrong, they’ll be believed. Other tests replay database migrations in a test database, or check the interface, such as contrasts and text sizes.
Network failures were tried by hand on 1 October: with the connection cut during “Done”, the entry stays on screen and “Retry” logs the exercise once only. The message says “not confirmed” and never claims failure, because a lost response can follow a successful write. A “Done” that moved on before the server’s response was rejected in the same spirit: without a local queue, the tick could be lying.
Screens and exchanges with the server mostly have no automated tests, by choice: they would need a database or three more dependencies. So a green test suite says little about what the person sees at the gym.
The limits we accept
The app doesn’t work offline. Yet that was one of our four design constraints, because many gyms have poor coverage in the basement. Nothing is saved without a network, and a closed app loses the current entry. Working offline would need a local queue and synchronisation, which means a different architecture. We ruled it out on 1 October and kept the safety net described above. The constraint is still written down, marked “not met”.
TRAME is a web app that installs on the phone’s home screen. For a mobile app development project, that form has its trade-offs: the app can keep an old version in memory after an update, and the iPhone’s native calendar remains out of its reach.
Developing a custom web app in Switzerland also raises the question of place. TRAME’s database is in Zurich. Its pages are computed in Frankfurt, because its host has no region in Switzerland.
Finally, all of this rests on one person. Access rights, roles, data migration, training a team, connecting to an existing tool: TRAME proves nothing on these subjects, which most business apps run into. Our measurements describe a single use. They guide our decisions and establish no general rule. Nor do we apply our own rule everywhere: the free-text note, with no entries from 1 September to 26 October, is still there.
The method, applied to a trade
Before looking for an app developer, in Switzerland or elsewhere, this is what we would do, in this order.
When bespoke isn’t the right answer
What follows is our opinion, drawn from this project, not a statistic.
Software on the market already does the job. Our own example shows it: training apps exist. TRAME rests on a preference for how it logs and on its status as an internal project. An SME needn’t think that way. If existing software covers the task, with a few detours, we would start by keeping it.
Nobody has access to the field. Without observation, you’re programming a hypothesis. This whole story rests on real sessions and on a database that can be read back.
The task is rare, or not yet stable. If the team doesn’t yet know how it wants to work, a spreadsheet or an existing tool will provide the answer first, with less commitment.
Nobody will look after the app once it’s in service. TRAME changed programme on 17 September, moved its computation on 1 October and lost its effort question on 26 October. Those changes came from the field, from measurements or feedback that someone read. An app delivered then left alone will make none of them.
Bespoke makes sense when a strong, precise constraint of use isn’t respected by any existing tool, when someone can go and see, and when someone will go back over what happens after launch. For custom software in a company, our custom business applications offer describes how we proceed. The first conversation starts from the task to simplify, the people involved and the tools already in use.
Reading frame
This story describes an internal OSOM Labs project, designed for one person. The app is not public. The rules mentioned describe how it works: they are neither training advice nor health advice. The measurements cover a single use and cannot be generalised.
Key takeaways
A business app starts from a situation of use written in one sentence. For TRAME: at the gym, on a phone, between two sets.
An effort rating offered on every set received 0 entries across 38 sets. Its last version left the screen on 26 October 2026.
A heavier load is suggested, never applied automatically. The log starts from the last time that exercise was done, or from a target the person set themselves.
An unknown value stays unknown: no numbered increase without a checked increment, “Duration unknown” rather than “0 min”.
286 tests check the app as of 3 November 2026. Screens are mostly not among them, and it doesn’t work offline.
Bespoke is hard to defend when existing software does the job, when nobody can observe real use, or when nobody will look after the app once it’s in service.