During a free trial period, working closely with Lloyds Digital’s internal QA team, a total of 47 issues were identified, fixed, and retested.
The number itself isn’t the most important part.
What matters is when those issues were discovered.
Before production - not after.
That is the key point: bugs were found and removed before the final release.
More and more businesses today rely on applications as a core part of their operations. Software helps speed things up, streamline processes, and simplify everyday work. In the hospitality industry especially, applications that support reservations and ordering have become an essential part of running a restaurant.
Our client, Lloyds Digital, developed software that now runs smoothly and intuitively helps users book tables, order food, or spend an enjoyable evening at a restaurant.
The product was close to going live. Builds were arriving regularly, most of the functionality was already in place, and the team had invested a significant amount of time in internal testing. At first glance, everything looked fine.
Still, in the background, there was a certain level of uncertainty about how the software would behave once it reached real users.
But it wasn’t always like that before launch.
With reservation-based applications, there is no room for error. If something doesn’t work, it becomes obvious immediately - often before users even step into the restaurant, already leaving them with a negative experience.
That’s exactly where Lloyds Digital was when we began working together. They had an application that worked, but there was still a question mark: would it work reliably in all real-world conditions once released?
That’s why we agreed on a short, free one-week QA trial. The goal was simple: testing the product the way real users would use it, in real-life scenarios.
Lloyds Digital is based in Croatia and has been around since 2014, operating out of the small but vibrant town of Labin. Over the past 12 years, they have grown into a solid team of around thirty people — designers, developers, and product specialists.
Many of the products they build are easy and intuitive for end users. Behind the scenes, however, there are numerous challenges that must be solved for an application to run smoothly and reliably. As mobile phones have become an integral part of our daily lives - used not only for communication, but also for work, entertainment, and everything in between - it’s clear that behind every seemingly simple app there are admin tools, B2B systems, and business logic that must work flawlessly at all times.
This is the context in which QA carries special weight and responsibility. When a system like this fails, it’s not just a technical issue. The process breaks - and more importantly, trust breaks. Ultimately, the business feels the impact.
Lloyds Digital already had an internal QA team in place. Testing was ongoing, and bugs were tracked as part of a regular cycle. At first glance, nothing was on fire.
For one week, we worked side by side with their QA and development teams. We used the same tools and the same Slack channels. No new processes were introduced — we simply joined a team that was already working closely on their product.
We intentionally did not start with formal test cases. Instead, we used the application. A lot.
We tried booking tables the wrong way.
We changed languages in the middle of user flows.
We moved quickly through screens to see where the system would break.
We tested things that usually work — deliberately looking for what happens when they stop working.
By the end of the trial, there was no more guessing. It was clear what was stable, what still needed attention, and how close the product really was to release.
Even though Lloyds Digital had its own QA team, they needed an external and independent perspective before launch. Tech Tailors, a company offering a free QA audit for startups, was a natural choice as a partner ahead of release.
After a few initial meetings, we moved straight into testing. Two QA engineers from our team started testing the beta version of the application. At first glance, everything seemed stable and functional.
After several days of testing, however, the picture became clearer and more realistic.
Small bugs began to surface.
Some reservations could not be completed.
In certain cases, the same table could be reserved multiple times.
Crashes appeared during filtering.
CMS data didn’t always remain consistent during rapid actions.
Validations worked inconsistently.
In some places, the wrong language appeared.
Individually, none of these issues were dramatic. Together, however, they sent a clear signal that the application was not yet ready for the iOS and Android app stores.
Most of our time was spent on the parts of the system people use every day.
The iOS and Android mobile applications were the main focus — not just individual screens, but complete flows: registration, restaurant browsing, reservations, and confirmations. Each process was tested multiple times and carefully documented.
We also tested the admin CMS and the B2B platform used by restaurant managers. This is often where problems hide that aren’t obvious at first glance.
What worked particularly well was speed and open communication.
Bugs were logged directly in Productive or Jira.
Developers picked them up quickly.
Fixes were delivered.
We retested.
And moved on.
Day by day, the system became more stable.
After one week, the difference was obvious.
Critical issues had been fixed and verified.
User flows became more predictable.
Edge cases were kept under control.
Before production, the application reached Stable status.
QA didn’t just find problems — it helped the team reach stability before users ever saw the product.
At the end of the one-week free trial, the team didn’t just receive a bug list.
They gained a clearer view of real risks.
Insight into what was truly blocking the release.
A QA process that works under pressure.
Better collaboration between QA and development teams.
And perhaps most importantly, a foundation was set for automation in the next phase — once the product had a stable base worth building on.
In practice, QA stopped being seen as a cost and became part of decision-making.
Before release — who actually tells you your software is ready?
QA doesn’t slow teams down, and it isn’t a cost — it’s an investment in reliable software. What truly slows teams down are production issues that have to be fixed under pressure.
In this case, one focused weeks of QA testing helped Lloyds Digital go to market with fewer unknowns and much more confidence.
Sometimes, all it takes is a short, honest QA period before release.
Let’s talk.