A 200-person company running on one no-code app.

safety4you, an Austrian railway operations company with 150 to 200 employees, grew from 10 people to 200 on Microsoft Office and paper. Car availability was tracked on a whiteboard, accidents were reported by WhatsApp, and workers posted their pre-shift safety forms to head office.

The company's apps were built by Alexander and his team at kwapso, a five-person no-code and AI-code agency, and he is the one telling the story. The run cost is roughly €300 to €400 a month for the whole stack, depending on active users, with Glide about 80% of it.

At a glance

• safety4you provides railway operations services to Austria's main railway operator, with up to 200 employees in an industry so regulated that even the office waste management gets audited.
• safety4you grew from 10 people to 200 on Microsoft Office and paper. Car availability was tracked on a whiteboard, accidents were reported by WhatsApp, and workers posted their pre-shift safety forms to head office.
• Fleet management came first, because 150 employees each need a car to reach their shifts. Cars had become the second biggest cost in the business after wages.
• Putting repair invoices against individual cars saves about €25,000 a year on mechanics, by Alexander's figure. The fleet manager can now see a part replaced 5,000km after it was last replaced, and ask why.
• Every department then asked for its own version. One app now holds fleet, damages, incidents, pre-shift risk analysis, audits, recruitment, employee records and a small sales pipeline. It is built in Glide, a no-code tool that turns a spreadsheet or database into an app people can use on a phone or in a browser.
• Across all of it Alexander calculates roughly 700 hours a year of back-office time saved, which he values at €45,000 to €50,000 at an average Austrian rate. The first AI piece, an agent that checks fuel card reports, is in testing now.

safety4you started in 2010 with about 10 people and now employs between 150 and 200, more in summer than in winter, with 25 in the back office. The work happens on live railway, so almost everything has to be provable, from the protocol for starting a shift to the protocol for an accident on the track.

The company ran the way most growing businesses do. The owner needed something, reached for Microsoft Office, and somebody made a template.

Alexander wanted to share this case because he thinks companies like this one matter more than the ones usually written about.

"90% of all of our economy is made by this type of businesses."

— Alexander

He means medium-sized local firms rather than enterprises or startups.

Before: a whiteboard and a set of disconnected Excel files

Every employee needs a car to reach shifts across the country, so the company runs a fleet of around 150 vehicles. This is how it was managed.

• Availability lived on a whiteboard in the office, with plate numbers written up and marked as available or out with a driver.
• Employees reported accidents however they liked, usually by WhatsApp or email, with no standard set of details.
• The accident report was a paper form kept in the car, full of small technical fields. That was hard going for the many workers who don't speak perfect German.
• Mechanics sent their invoices to the back office, where they were paid as bills and never attached to the car that was repaired.
• Car details and damage history sat in Excel files, with claims recorded against the number plate.

What changed: cars became the second biggest cost in the business

As the company passed 150 employees, the fleet became its largest cost after wages, and the team could see the whiteboard wasn't keeping up. They had also noticed that mechanics were charging them a lot, and nobody had the overview to question it.

The company named fleet management as its own first problem, and Alexander thinks that mattered more than the tool.

"I would've never sent them a cold email saying, 'Hey, I can fix your auditing,' because I would've not known the problem."

— Alexander

What they built: one Glide app with a relational database underneath

The team started by getting the data out of the spreadsheets. They imported every car the company had bought and every damage already on record, so the app opened with history in it.

• Each car has a unique ID, so plate numbers can be added and removed over its life while the claims stay attached to the right vehicle.
• Employees link to cars, so a driver's damage history follows them across every car they have driven.
• Repair invoices are uploaded against the car, which puts one vehicle's full repair history in one place for the first time.
• Roles decide what people see. The fleet manager runs it, the back office and the audit team can view it, and employees see only their own cars.
• The insurance broker has his own login, which shows him the damages he needs for claims and none of the other car details.
• Employees get the car rules in the app, next to the documents they have signed. Nobody can say they didn't know the company car wasn't allowed abroad.

The accident report became a digital form on the employee's phone. Alexander's team asked the insurance broker for the minimum he needed, and built the form around that.

Result: about €25,000 a year saved on mechanic invoices

• The company saves about €25,000 a year on mechanics. That is Alexander's figure, and the one he offers when asked for hard data.
• The saving comes from questions the fleet manager can now ask. With every invoice sitting against its car, he can see brake discs replaced 5,000km after the last set and ask the mechanic why.
• Claims now reach the broker with the details he asked for, including photos. Claims used to fail because of missing details, though Alexander says nobody can put a figure on what the insurer would have paid.
• Damage history is now continuous for each car and each driver, across plate changes and vehicle swaps. The spreadsheets could not do that at all.

Reality check: some of the saving comes from mechanics knowing someone is looking

The question to ask of any system like this is how much of the saving comes from the software and how much from attention. A mechanic who knows his customer now reads every invoice may start charging less, whatever tool the customer uses.

Alexander's answer is that the saving traces to specific invoices being questioned, like a part replaced too soon. Before the app, one person could not track 150 cars, and the fleet manager did not even receive the invoices.

Both effects are likely at work, and both needed the app. The attention only became possible once each invoice sat against its car.

Your first step: put your invoices against assets, not dates

Take the thing that costs you most after people, whether that's vehicles, machines or premises, and give each item a permanent ID. Then put your last few repair invoices into a sheet with one row per invoice and a column for that ID.

Ten minutes gets the sheet started, and sorting by ID will show you the repeats. The €25,000 came from an invoice being attached to the right car.

The strongest objection to any business that has its software built by someone else is dependence. Here a company of 200 people runs its fleet, safety records, audits, recruitment and training on apps built and maintained by a five-person agency.

Take that seriously if you are in the same position, whether your builder is an agency, a freelancer or one internal developer. safety4you's setup answers it in three ways.

The platform is a commercial no-code product. The app and its data live in Glide, which other agencies and freelancers also build on, so another builder could pick it up.

Requests go through a ticket system. Ideas and problems are written down, so the reasoning behind each feature is on record.

The client has learned to describe its own processes. The first build was difficult because people could say what they did but not why, or which steps were law and which were habit. Alexander says every head of department he works with has got better at this.

That third point is worth copying whoever builds your software.

"It forces them to write it down."

— Alexander

A business that can explain its own processes can brief any builder.

Start with one problem that has money attached. Fleet was the second biggest cost in the business, and a win there earned the trust for everything since.

"It worked because we found a specific example like the fleet management, and then you have a little win, then you can move forward."

— Alexander

Let the next department come to you. The audit team saw the fleet app and asked for car protocols, then the risk analysis, then their own audit module.

"They just come with ideas suddenly, and then it just becomes this loop."

— Alexander

Make people write it down. The hardest part of the first build was learning why each step existed. A ticket system that makes people describe the problem in writing has made every later build easier.

Keep the use cases small.

"None of them are crazy use cases. None of them is technically super complex. They all solve a specific problem."

— Alexander

Ask one question to get started. Alexander's opener for a business like this is to ask for one thing they still do the way they did it years ago. He then shows how it could be done, and they find the rest together.

Case studies are published to help readers understand how other organisations approached a problem. They are not endorsements of a tool or a vendor, and one company's result is not a forecast of yours.

Continue reading the full case study →