Jan Mikoláš
I start by understanding the goal
First, we clarify what you need to solve, who will use the solution, and how the process works today.
About
About me
I’m Honza, and I help companies streamline their operations through web applications, automation, and connected systems. I prefer long-term collaboration and have the most experience with e-commerce, internal tools, APIs, and integrations. I can help remove unnecessary manual work, connect the services you already use, and support the ongoing development of your application. What I enjoy most about development is understanding how things really work, removing unnecessary complexity, and designing solutions that are easy to use and help businesses save time, reduce costs, or increase revenue.
I’m primarily a backend developer focused on PHP, but I also regularly make frontend changes. I’ve been developing web applications since 2007. My experience spans my own projects, running online stores, the long-term development of an e-commerce platform, and working as part of a larger development team. That practical experience helps me look beyond the implementation itself and consider both long-term maintainability and the real needs of the people who use a system.
My story
From my first websites to systems used by thousands of people.
I first came across programming on Windows 98, when a friend showed me how to make simple games in C. Before long, though, I was more fascinated by the internet and the possibilities it opened up. In 2007, I started building my first websites and gradually focused on PHP. Together with a designer friend, I created an online project that grew to around 5,000 visitors a day. It was my first experience of seeing something made at a home computer become part of thousands of people’s daily routine. We later sold the project, and its new owner built on its audience and strong search visibility.
With the first money I earned, I bought Steam and gear for playing Counter-Strike. Over time, helping the community grow became more interesting to me than playing itself. I learned to manage servers, organise tournaments, and run gaming leagues. I was frustrated by how cumbersome competitive match servers were to operate, and by the fact that a player banned on one portal could simply carry on elsewhere. So I learned to write plugins and built a tool that made competitive server management easier. Later, I founded the forFAIRPLAY portal, bringing several competing portals together around a system for handling protests, bans, and player cheating. API integrations made the process more transparent, efficient, and automated.
Around the same time, I became increasingly interested in web application security and in finding unexpected states that may not have been considered when an application was designed.
Automating fares for Veolia Transport
During my studies, I completed a placement at Veolia Transport, among other places. In the marketing department, I was shown an extensive Excel fare sheet and the manual process used to recalculate it. It seemed unnecessarily complicated, so I spent most of the placement creating macros and rules that automated a large part of the calculations.
It was one of the first times I realised that I enjoy more than simply writing code. I especially enjoy understanding a process first and removing needless manual work from it. That way of thinking has stayed with me through later projects.
My first online store and first larger integration
It was 2013. I had already built a few websites and it was time for my first full-time role. I joined a wholesaler selling women’s underwear. My first assignment was to create Moderni-Boty.cz, my first online store, and integrate it with a local supplier.
While developing it, I noticed that the same products could be bought much more cheaply elsewhere. I spoke up, and we soon connected the store to a different supplier. Lower prices, automation, and an established network of underwear buyers then made it possible to offer the whole range wholesale as well. I designed and built an API for partners’ automated orders, optimised the store for mobile, and worked on SEO. Within a few months, it ranked highly for searches such as “women’s court shoes” and “women’s trainers”. The API was later used for the underwear business too, making ordering easier for partners and helping the company grow its revenue.
Running my own online stores
My work on that first store drew me deeper into e-commerce. I tried running a dropshipping store and then began operating my own stores end to end. Suddenly, I was not just a developer. I dealt with suppliers and marketing, spoke with customers, bought stock, packed orders, and sent parcels. That experience changed how I see development. A feature that looks right to a programmer does not necessarily work well for the person using it every day. Behind every order, stock level, price change, or product import is a real process — and often a person for whom a well-designed system can save hours of unnecessary work.
When I started running several stores, I ran into exactly that problem myself. Each store had its own administration and many tasks had to be repeated. Products, images, imports, changes, and new features were all handled in several places. So I began building a system for my own use that brought the management of multiple stores together.
A system alone is not enough
I am not a salesperson. I am a developer who enjoys simplifying processes. I had built a system that made it far easier to manage several online stores, but the system alone was not enough. It needed commercial backing, customers, and someone who could turn it into a working business. So I approached a former employer about working together. One conversation led to another, and for the next nine years I could focus on my strengths: developing and evolving the platform. From one central administration, we gradually managed around 30 online stores. The main one was Amiatex, which sold not only in the Czech Republic and Slovakia, but chiefly in Hungary and Romania as well as other EU countries.
We gradually expanded the platform with more languages, currencies, suppliers, carriers, payment methods, and marketplace integrations. Long-term development gave me experience that is hard to gain on a project lasting only a few months. It is not enough to design and build a system well once — if it is to serve for years, it has to keep adapting to real-world operations. Requirements change, integrations are added, technology evolves, and some decisions that made sense at the time would be made very differently years later. Yet you cannot simply throw such a system away and start again when a company’s daily operation depends on it.
From a one-person show to a team of dozens
After years of mostly working independently, I also experienced a very different environment. At Sportisimo, I joined a development organisation of around 40 developers. I worked in a five-person sub-team on an internal system for shop staff.
It was an important experience for me. The question was no longer only how I would solve a particular problem myself. Every change could affect the work of other people and teams. Shared ways of working, dependencies between teams, code review, communication, testing, and thinking through the impact of a change mattered just as much as the code itself. Today, I know both worlds: the independence of building and evolving a system over the long term, and development as part of a larger team.
Not everything worked out along the way
Looking back, my path has not been a string of successful projects. There have been plenty of dead ends, ideas that did not work, poor decisions, and projects that ended sooner than I would have liked. Most are not listed among my references, but I still see them as an important part of the journey. They taught me about technology, business, collaboration, and how I would approach the same problem differently next time.
I tend to build for the long term. I enjoy getting to know systems gradually, developing them, and seeing how they change over the years. At the same time, I have learned that not every good idea can be taken all the way, not every collaboration lasts, and even a good system may not exist forever. The experience stays with me, though. It helps me understand more clearly what may work in a project and where problems can arise.
What I enjoy about development today
Today, I focus mainly on backend systems, e-commerce, APIs, integrations, and automation. Technology has changed many times since I started and will change many times again. To me, it is primarily a tool for solving a specific problem. I take the same approach to AI: it is a normal part of my development work, speeding up research, design, and implementation, while responsibility for understanding the problem, architecture, security, and the final solution still remains with me.
After all these years, what I enjoy most about development is much the same as it was at the beginning: understanding why something does or does not work, finding a problem worth solving, and designing a fitting solution that people will actually use. One that saves them time and money, gives them a clearer picture, and makes their processes more efficient.
How I collaborate
Solutions tailored to your needs.
I propose a clear approach
I outline how we will proceed and choose a solution that works today while leaving room for future growth.
Development
I keep you updated as the work progresses, and we check together that everything works as expected.