We started with the smallest useful version

We did not begin by replacing the company's entire operating system. The first priority was to remove the most repetitive work, so we built a Telegram bot as an MVP.

A manager could send it a client conversation or a technician's CV. The system analysed the text, extracted the useful information, and saved it as a task or technician profile.

For new requests, it also returned the ten most relevant specialists from the existing database.

The right skills were only half of the match

TechPRO works with technicians located across the country. Finding the right technical experience was not enough. The specialist also had to be able to reach the job.

A technician might:

• work only within their own city;
• travel to nearby cities;
• accept work across connected regions;
• travel anywhere in the country.

A specialist could be an excellent technical match and still be irrelevant if the job was outside their working area. So the matching logic had to account for both capability and real geographic availability.

The system evaluates the task against structured technician data: equipment, control systems, software, previous experience, city, and travel radius.

From a request to a confirmed candidate

Automation without losing control

The system handles repetitive work, narrows the search, and keeps information synchronised. The manager can still:

• inspect every suggested technician;
• open the full professional profile;
• view candidates outside the initial selection;
• change a candidate's status;
• assign someone manually;
• decide how far outreach should expand;
• choose the final specialist.

It reduces what a manager has to remember without taking away judgement or control.

Built to grow beyond matching

What began as a bot for structuring requests has become the foundation of a broader operational workspace for TechPRO.

The next step planned by the founder is to build on the same foundation and extend the system into contracts, estimates, document generation, successful-deal analytics, and financial records.

The product continues to grow from the way the company actually works, not from features added only to make the system larger.

It started as a database migration

The restaurant already had its own CRM, initially assembled by the founder with AI tools and later refined by a frontend developer.

My task sounded straightforward: replace JSON files and localStorage with PostgreSQL.

But once I examined how the product worked behind the interface, it became clear that changing the database would not be enough. The backend was not designed for reliable daily operations, and too much of the product logic depended on a fragile technical foundation.

What began as a storage migration became a full backend rebuild.

The larger problem was outside the CRM

The restaurant used an external SaaS provider for its customer-facing website and mobile app.

The platform was expensive, but cost was not the only issue. Order status updates could fail to reach customers, menu changes were not always published on time, and products placed on the stop list could remain available for ordering.

For a delivery restaurant, these were operational problems rather than minor software inconveniences. An outdated menu or a missing status could lead directly to cancelled orders, manual calls, and frustrated customers.

The goal became larger: turn the restaurant's own system into the POS behind the existing website and app.

The integration was almost stopped before launch

Part of the integration had already been developed using the provider's documentation. But when it was time to connect the real restaurant, the provider said that API keys were not issued for custom POS integrations.

Only prebuilt integrations were officially supported — including the ones the restaurant was trying to replace.

After a series of discussions, the provider approved the custom system and granted access. The integration was first tested on a separate restaurant profile. The production restaurant then had to be recreated, its settings and menu transferred, and the connection configured again.

The challenge was no longer just building the software. It was getting a custom product into production inside an ecosystem that was not originally prepared to support it.

From a CRM to an operating system

The new platform became the restaurant's central workspace.

Orders from the website and app enter the system with the customer, address, items, payment details, delivery method, and operational notes. Employees manage the full order lifecycle from the same interface:

New → Preparing → Ready → Out for delivery → Delivered → Completed

Every status change is sent back to the customer-facing platform, while the restaurant keeps its own structured history of the order.

The system now brings together:

• order processing and status management;
• menu items, categories, modifiers, prices, and availability;
• separate settings for different branches;
• preparation and delivery timing;
• courier and branch performance;
• revenue, order, average-check, and peak-hour analytics.

Instead of adapting daily work to several disconnected tools, the restaurant now has one system built around its actual process.

Delivery became a measurable process

Completing an order is not the same as delivering it on time.

The platform compares the expected delivery time with the actual completion time and automatically calculates on-time deliveries, delays, and average lateness. Performance can be reviewed by courier or by branch.

This gave the owner a visible operational picture instead of relying on individual complaints or manually checking completed orders.

Control now. Independence next.

The restaurant no longer depends on the quality of a prebuilt POS integration. Orders, statuses, menu data, delivery performance, and analytics are managed within its own product.

The next stage is already in development: a customer-facing website and application connected directly to the same operational system.

Once launched, they will remove the remaining dependency on the SaaS provider and give the restaurant control over the entire digital journey — from browsing the menu to receiving the order.