ISATEK’s origins and operating philosophy
ISATEK is a distributor of industrial equipment for powder and bulk solids handling in Greece and neighboring countries. The company grew out of TECTRA Ltd and has inherited not only the customer and supplier portfolio, which we have grown beyond what had been built over thirty plus years, but also the very pragmatic, down-to-earth working processes that TECTRA Ltd had implemented until 2020.
When I returned from abroad in 2020 to take over the business’s operations, I kept those processes alive for 1.5 years as I struggled to keep up with the increasing market demand towards a now-reinvigorated business.
That’s why I brought in various APIs that I developed in Python back then, using Django and FastAPI, to digitalize the business’ operations and get rid of the drudgery of data search and data entry.
Thanks to those efforts, the administrative part of the work became doable within maybe two hours a day. This freed me up to focus on growing the business into new segments, introducing new products, and expanding the product portfolio by importing from new suppliers like Solimar Pneumatics in the US.
Our philosophy is simple and clear: stay pragmatic, keep processes efficient and non-bureaucratic, maintain full control over the data, and keep improving how the work gets done by reducing Non-Value Added work by building internal tools that match how we actually work after thirty-plus years of real experience. We do not chase generic solutions or trends. We evolve what is battle-tested.
What makes ISATEK different from other industrial equipment resellers
ISATEK stands out as a differentiated distributor in Greece. We focus on getting the job done in a way that nobody else does. Sure, in a simple way we resell equipment that we import from abroad, such as from WAMGROUP and Fike .
But what justifies the distributor margin, and why did the customer base grow by around 20 new customers per year since 2020?
It’s the know-how. We are focused on the customers’ needs, concretely on their needs for an application they have, even though they themselves might not know enough to select the right equipment to get the job done with a low Total Cost of Ownership and Operation.
We provide the process engineering and particle technology know-how that most (all?) other resellers of similar equipment in Greece seem lack due to limited education and experience. Providing after-the-fact solutions to process-engineering problems that were not solved by the equipment purchased by other resellers has not been a rare occurrence.
But this is already “nailed down”. What’s next? My own aim is to digitalize the business further so that we turn into something that the market in Greece is currently not experiencing. While still keeping around the old microservices and APIs for as long as they still serve their purpose, the goal is to digitalize all processes, maintain and even improve the responsiveness of the business, and make the management of commercial cases, import cases, and other types of cases so easy that filing emails, documenting delivery notes and invoices, tracking financials, providing feedback to the customer on the state of their order, and everything else can be done with as few clicks as possible. The goal: no more wasting precious time and mental capacity copying things back and forth on network drives or SyncThing across all my computers and my mobile phone.
Why I reject off-the-shelf or COTS ERP/CRM software
One could argue that all this is done with an off-the-shelf ERP/CRM system, and for sure, there are many of those in Greece. However, the market has consolidated into a semi-oligopoly over the last few years.
The real problem is this: all those vendors have you run the business according to how they have designed the software. They try to cater to all kinds of businesses that do similar import and reselling work across different industries, which means that using such software would impose business processes on use that are not our own.
Our processes have organically evolved over thirty plus years to be efficient, non-bureaucratic, clear. They have been battle-tested across thousands of customer invoices and supplier invoices. They work with the minimal effort and maximum result after organically getting improved over three plus decades.
That doesn’t mean that how we work must be how others work. But it does mean that off-the-shelf software would force on me a straitjacket that I have to pay for every month through a software-as-a-service subscription. I don’t control the data or (most importantly) how it’s stored. I cannot request new features and know for sure that they will be implemented. None of the affordable ERP/CRM systems I’ve evaluated feature the possibility of integration with my on-premises self-hosted IMAP server that carries all emails since ca. 1997.
I refuse to operate that way. If I need a feature, I need to at least know that it will be implemented, and by when. Most software businesses out there, especially if they are incumbents resting on their laurels , are unlikely to implement what I need, at the quality I need it, by the time I need it: as soon as possible. Understandable. But not acceptable.
If you want something get done under your specific conditions, and you can do it yourself, then you should do it yourself.
Introducing Emporoman
That is why, around six months ago, I started playing around with a prototype of an Elixir Phoenix LiveView app. That prototype has grown to become a daily workhorse of ISATEK’s operations. The name of the software is Emporoman, a play on «Εμπορική Διαχείριση» (“Commercial Management).
Emporoman is deeply tied to how TECTRA Ltd and nowadays ISATEK get the job done, so it will probably never become a public Software as a Service. However, it has already grown sufficiently to start serving as a backend for new features that will become part of isatek.gr either towards the end of 2026 or in early 2027, as time permits and needs dictate.
Emporoman is implemented in Phoenix LiveView. The tech stack is purely self-hosted. It runs on a single VM on our own on-premises Proxmox VE server. That VM runs the Elixir app, the PostgreSQL 18 database, and Garage for S3-compatible object storage. There are no monthly expenses for cloud services.
The goal is to keep things frugal, pragmatic, and absolutely crazily tailor-made for the current operating mode of ISATEK, based on years of experience enhanced by the custom REST APIs I developed in 2021 and 2022.
Core features
You register your own business first. Then you register customers, suppliers, OEMs, end users, resellers, etc.; i.e. any kind of company that is within your business’ universe. After that, you can add contacts to every company and add the email address, phone numbers, department, job description, notes, and so on.
In fact, every single record in the database can have notes attached through an association table that carries notes that are rendered if in Markdown. You can add notes on a contact, on a company, on a payment, on a transaction, on a commercial case, on a stock movement, and so on. It’s not rocket science or brain surgery, true. It’s a basic association table with an extra field. The value of this feature far exceeds its triviality in terms of implementation.
We have %Case{} records that mix ERP and CRM functionality. You can register multiple warehouses. As ISATEK has started moving from its downtown Athens headquarters to the old TECTRA Ltd site in in the suburbs, the needs have grown to include managing inventory across locations without Excel sheets or constant copy-pasting between PDF files and forms. This includes the gradual depletion of TECTRA Ltd’s old inventory.
Stock movements pull item codes and descriptions from the custom Product Items API (which is what I’ve been reimplemented in Elixir and Phoenix in the Phoenix Product Codex book ).
Every %StockMovement{} has a type: purchase, import, sale, transfer, etc. I use use Weighted-Average Costing to track inventory valuation on a per-item-code basis. This model is simple and workable for our fungible industrial equipment items that are not usually serialized and have very low failure rates (concretely: 4 warranty cases in thirty-plus years).
The system can even take a JSON extract of a delivery note or invoice (typically extracted by ministral-3:14b-instruct-q4_K_M with a custom prompt) and automatically import a series of grouped stock movements into the warehouse of my choice. It also handles the Greek tax authorites’ myDATA API, and thus every single invoice that has a record is linked to the PDF document I upload and link to a %Case{}.
On the financial side, you can register %Transaction{} records that are associated with a %BankAccount{}. Many months ago I implemented a parser for Eurobank’s CSV exports of account statements. The relevant context module fingerprints every row so that Emporoman “knows” which transactions you have already imported and avoids duplicates. Every %Transaction{} must be associated with a %Company{} and a %Case{}. In combination with keeping track of invoices issued by ISATEK by querying the myDATA API, I can know which customer owes what.
Email integration is the real game-changer right now
The part that has really untied my hands is the email integration. Using my own fork of Plover , Emporoman connects directly to the on-premises self-hosted Dovecot IMAP server. It acts as a read-only email client inside the web app.
When you preview a message, it detects if there are registered %Contact{} records with those email addresses of the sender and the recipients, finds the company, and shows all currently open cases. You can then open the email in the :show action and file it with one click into the correct case folder.
Every case has a unique ID, which is a ULID. We take the first nine characters of the ULID and add dashes to make it readable. This “case identifier” is used across offers generated by the Offer API , purchase orders, proforma invoices and delivery notes issued as PDFs generated from ODTs (because who needs Microslop Word when you have LibreOffice?), and so on.
All attachments are also reachable through the web UI. I can access everything on the go through the self-hosted WireGuard VPN.
Future plans, and the broader vision
Emporoman is currently purely internal, but the next steps are clear: it will serve as the sister backend for isatek.gr. Customers who reach a certain volume or trustworthiness will get login accounts. They will be able to track all their orders (just like what TECtrack used to enable up until 3 years ago), see invoices and delivery notes, product specs, and history. This cuts out a huge amount of Non-Value-Adding administrative work for keeping customers up to date.
The third part of the broader vision is Pragmata : my upcoming distributor-led asset management solution.
When we deliver equipment, we also deliver a digital folder for that item. Every physical good being delivered is accompanied by a digital record as an asset, just like every real-estate property on Breek.gr has its own digital folder. Customers can associate the asset with locations and production lines, store manuals, see spare parts recommended by ISATEK for that equipment (or that specific serial number), get maintenance notifications (for example, “replace the filter elements of your WAM SILOTOP filter because it was last done 12 months ago”), and send requests for quotation directly. This will dramatically reduce my own internal effort tracking incoming requests.
I also believe that the real value of modern AI systems lies in mixing plain business-rule automations and workflows with LLM natural language processing and structured JSON extraction capabilities. This enables automatic filing, smart notifications, and more. In the era of agentic coding, many say pure agentic systems are the pinnacle. I beg to differ. The hybrid approach is far more useful for real business operations, where we already have plenty of already-structured data mixed with data that’s in natural language (emails or Requests For Quotation or Purchase Orders) and data that’s tabular but trapped in the layout of a PDF (and thus amenable to structured JSON extraction by a self-hosted LLM).
Emporoman started as a weekend experiment many months ago, and reached a deployable state last week, without any agentic coding, but after extensive discussions of the product vision, software architecture, tech stack, requirements and features with Grok 4.20 in Expert mode.
Today it is already my daily workhorse. This proves that when you have deep domain experience and the ability to build exactly what you need, you can create something far more powerful than any generic system. This is how ISATEK stays in control of its business domain while remaining frugal/non-wasteful/cost-competitive in terms of operations, and keep moving forward on our own terms, turning thirty-plus years of real operational knowledge into the foundation for ISATEK’s next phase of growth.