A technician finishes a long day on site, gets back, and still has paperwork to do. What did they work on? For which customer? How many hours?
Then someone else needs that information in a project tracker. So the same work gets recorded again.
At Sensem, a Spanish door manufacturer, this was part of the daily routine. Technicians checked in about their planned work in the morning, then headed out. Eight to ten hours later, they were back at the office trying to remember the day well enough to fill in a timesheet.
Pascual Brines described the old process this way, translated from Spanish:
"Previously, we recorded it by hand on paper... This was the template we used to record each worker's daily tasks."
Hours were only part of it. Details about the job got forgotten before anyone wrote them down. Notes that could have helped a manager plan the next job or understand why something took longer never made it off site.
It wasn't a business requirement, but one question kept haunting me: "How do I make their business ops better without making people work more?"
Notes. Let people write down what happened while the job was still fresh in their heads, alongside the hours they were already recording. Managers get the details they need, and technicians don't have to reconstruct their entire day from memory. That's the direction I wanted to take it.
I had one contact and ten people to build for
I took on the project while working at Neotic, around January 2025, as part of its work helping Spanish businesses digitalize their operations. At the time, Spain's Kit Digital programme offered EU-funded grants to help small businesses and self-employed people adopt digital tools.
My contact was Pascual Brines, Sensem's Product Manager and owner. He explained what the business needed, brought back feedback from the team, and made decisions with me. All our conversations were in Spanish. The application would be too.
There were roughly ten people to build for: seven technicians and three project managers. Most of the technicians were older, in their forties, fifties, or beyond, and weren't particularly tech-savvy. They needed to record their work and get on with their day.
I wanted the app to be idiot-proof. There's nothing sexy about having to walk every technician through a new piece of software just so they can log their hours. That's more work for them and for whoever has to explain it.
Software should be simple for its users and still do what the business needs. Open it, know what to do, do it, close it. If someone needed a tour every time they wanted to log their hours, I hadn't done my job.
I worked out the requirements, proposed the solution, wrote the specification, designed the screens, and built it. Pascual had one person to call about the project. I had one person who knew the business and could get me answers.
The requirements were practical:
- Technicians could record hours against the right customer and project, with notes about the work.
- Managers could see those entries without collecting and retyping timesheets.
- Managers could control project status and manage staff accounts themselves.
- Reporting would show where time went and help managers distribute the work.
- The everyday flow had to be easy to use on a phone.
That last point would decide whether any of the others mattered.
A simple app was enough to solve this
Technically, this was a simple CRUD app. Create records, read them, update them, delete them. The sort of thing you might build for your final-year university project. Customers, projects, people, time entries, and reports.
The hard part was understanding how those pieces needed to fit into someone's working day. Bubble gave me a way to build the screens and their logic, with hosting included.
That meant I could spend more time on how people would use it. Setting up and maintaining a separate database, hosting, and deployment process would have added work without helping a technician submit their hours.
The subscription cost was acceptable to the customer. Neotic was also investing in low-code tools and training people to deliver projects with them. The client's needs and our way of working lined up.
Honestly, Bubble surprised me. I hadn't expected a low-code tool to let me do so much, and building with it was a pleasure. Its guides were actually useful too. If you're starting with Bubble, do the guides. They save a lot of guessing.
For someone who lives and breathes code, and these days an alarming number of Markdown files, building this way was a breath of fresh air. You could build something a real company would use every day without writing code. That's pretty cool.
There were rough edges too. A mobile dropdown in the management screens needed a workaround. Apparently even a small internal app gets its own tiny boss fight.
Logging the work took about 45 seconds
Managers created customers and projects. A technician opened the app, chose the customer and project, entered their hours, added notes, and submitted the entry.
That took roughly 45 seconds.
Each person had an account. Managers could add new workers, deactivate accounts, and give someone management access. Customers didn't need accounts. This was a tool for the people doing and organizing the work.
Technicians recorded what they had done. Managers used those entries to decide what happened next and kept projects marked as not started, in progress, completed, or cancelled.
The customer-call routine changed too. Previously, answering a progress question could mean calling a technician first. Now the manager could open the dashboard and answer from the recorded work and project status.
The reporting brought together hours and project counts per customer, average and median time spent on projects, project timelines, customer value, and technician workloads. Managers could see where the hours were going and where work needed redistributing.
It took five days to stop reaching for the paper
The whole project took about six weeks, including requirements, development, feedback, and delivery.
There was back and forth along the way. I adjusted screens and logic as Pascual brought me feedback, and refined the reports around what management needed to see. By the time the team started using it, the main workflow was ready. The remaining fixes were mostly small interface changes.
For the first working week, technicians used the app and kept filling in their paper timesheets. A chance to get comfortable and check that the new process worked.
After five days, they dropped the paper.
That's the bit I'm proudest of. I never spoke directly to the technicians. Everything came through Pascual. I had to understand their day, design the flow, and get it right for people who weren't particularly interested in learning a new app.
And they were the ones who decided they could drop the paper after a week. Along with management, they wanted to keep using what I'd built.
It felt like one of those rare releases where things actually land the way you hoped. A few small fixes, mostly UI, and the team was getting on with it. After all the thinking, building, and back and forth, that felt bloody good.
They could drop off their tools and go home
The client estimated that the new process saved each technician around 15 minutes a day. That was his informed estimate, rather than a timed study.
Across seven technicians and a 21-day working month, that's roughly 37 hours. It doesn't include any time managers saved collecting sheets, re-entering information, or chasing updates.
Fifteen minutes sounds small until you're the person filling in a timesheet after a long day. Getting that bit of your day back matters.
The end-of-day ritual became dropping off their tools at the office and going home. Sometimes they didn't need to return to the office at all. There was no timesheet sitting there waiting for them.
I know the app was used for daily operations for at least eight months, while I was still involved. We were available for support, but the client didn't request further features during that period.
There's something satisfying about that. I liked building it. They liked using it. And after a few small fixes, nobody needed me to keep explaining how it worked.
The paper had a five-day farewell tour. Then everyone got on with their work :)