At the forefront of innovation, we push the boundaries of technology, developing solutions that empower businesses to thrive in the digital age.
Our team of passionate experts brings together tech skills and industry know-how to create custom experiences that get results.
Whether you're a startup or a big company looking to change, we become your trusted partner, working together to make the most of technology.
An AI-powered development pipeline orchestrator. One prompt triggers a nine-step pipeline: branch, architect, code, review, fix, test, e2e, docs, merge.
AITM does not replace Claude Code, Cursor or whichever AI coding tool you like. It runs them. Point it at the models you already pay for and it adds the pipeline, the safety net and the project memory around them.
Visit aitm.cz
Crafting robust applications from front-end interfaces to back-end systems.
A full-stack engagement means one team owns the whole path from the browser to the database. There is no handover between a front-end supplier and a back-end supplier, and no argument about which side a defect belongs to. We build the interface, the services behind it, the data model underneath, and the deployment that carries all three to production. One team answers for the result.
On the front end we work with the current React and TypeScript ecosystem, though what we pick depends on the product in front of us. A content-heavy site and an operations console have different needs, and picking the same framework for both is how projects acquire weight they never shed. We care more about how the interface behaves under real data than how it looks in a demo with three rows.
The back end is usually a handful of well-bounded services, somewhere between one big block and thirty tiny ones. Most businesses do not have the traffic to justify the operational cost of many services, and the ones that do rarely need it on day one. We size the architecture to the problem in front of us and leave room to split it later.
Data modelling is where we spend the most care, because it is the one decision that is expensive to reverse. Schemas are designed around the questions the business will ask, because those outlive the screens we have today. Migrations are versioned and reversible, and every schema change ships with the code that depends on it.
Work starts with a short discovery: what the system must do, what it must never do, and which of the stated constraints hold up when we ask why they exist. That distinction matters, because a surprising share of technical requirements turn out to be habits inherited from a previous supplier. We write down what we agreed and keep that document alive as the build proceeds.
Every piece of work goes through the same pipeline: a branch, an automated review, tests, and a merge only when all of them pass. Nothing reaches production because someone was confident. The pipeline is the same one described under DevOps automation, and it applies to our own work before we ask it of anyone else.
You get the source from the first week, in your own repository, under a licence that leaves you free. There is no phase at the end where code is handed over in exchange for a final invoice. If you decide to continue with a different supplier, everything they need is already in your hands.
Documentation is written as the system is built, not reconstructed afterwards from memory. Each service carries a readme explaining what it is for and how to run it locally, and the decisions that shaped it are recorded with their reasoning. A new developer should be productive within days.
Flexible and iterative delivery that adapts to your evolving needs.
Agile is a way of reducing the cost of being wrong. No specification survives contact with real users, so what counts is how quickly the plan can change once reality arrives. We work in short cycles that each end with something you can look at and use.
A cycle is two weeks. It starts with a conversation about what matters most right now and ends with working software in a staging environment you can click through. Between those two points the scope of the cycle is protected, because a team that is re-planned daily never finishes anything.
What gets built first is what carries the most risk or the most value, whichever is more urgent. Features that are pleasant but not load-bearing wait. This ordering is uncomfortable at first, because the polished parts arrive late, but it means the expensive discoveries happen while there is still budget to respond to them.
Estimates are given as ranges and revised as the team learns. A single confident number is almost always fiction, and treating it as a commitment turns the first delay into a crisis. We would rather say what we do not yet know.
You see the work as it happens. The staging environment is updated on every merge, and you are welcome in it at any time. Most of the corrections that matter come from someone on your side using the thing and saying: that is not quite how we work.
Each cycle ends with a short review of the work and a shorter one of the process. The second is the one that compounds. Small frictions that nobody mentions cost more over a year than any single technical decision.
Written specifications still exist, and they are short and kept up to date. We describe behaviour through examples and acceptance criteria that can be tested, so both sides can check what was agreed.
Agile still needs a plan. There is a roadmap with a shape to it, and we revisit it every cycle. The difference from a traditional plan is that changes are expected, so nobody treats one as a failure.
Accelerating delivery and deployment with automation and CI/CD.
Deployment should be uneventful. When releasing is difficult, teams release rarely, and rare releases are large, which makes them risky, which makes teams release even more rarely. Breaking that loop is most of what DevOps work is for. The goal is a release that is small enough to be boring.
Every change goes through the same automated path: build, static analysis, unit tests, integration tests, and a deployment to staging. The pipeline is the only route to production. There is no manual override, because an override used once becomes an override used habitually.
Infrastructure is described in code and versioned alongside the application. Environments are rebuilt from that description, so staging and production cannot quietly drift apart. Anyone can see what the infrastructure is by reading it.
Rollback is designed before the first deployment, not improvised during the first incident. Database migrations are written so the previous version of the application still runs against the new schema, which is what makes a rollback something you can actually use.
We start by measuring what is actually slow. Sometimes it is the test suite, sometimes it is an approval step nobody remembers introducing, and sometimes it is one person who is the only one able to deploy. The remedy differs, and guessing wastes weeks.
Monitoring covers what the business cares about, which is usually harder to graph than CPU. Response times and error rates matter, but so do failed payments and queued jobs that stopped moving. Alerts are tuned so that an alert means somebody acts. A channel full of noise gets muted, and then you have no monitoring.
Secrets are kept out of the repository from the first commit, in a proper secret store with rotation. Retro-fitting this after credentials have spread through a codebase and a chat history is far more work than doing it at the start.
We prefer boring, well-understood tooling over anything novel. The infrastructure is going to outlive our engagement, and the people who inherit it should recognise what they are looking at. Anything clever needs to justify itself against that standard.
Visualising ideas before investing heavily, to test and refine your vision.
A prototype exists to answer a question, and the first job is agreeing which question. Will people understand this? Is this technically feasible at our data volume? Would a customer pay for it? Each of those calls for a different prototype, and building the wrong one wastes the time it was meant to save.
For questions about comprehension, a clickable mock is enough. It looks real, it responds to clicks, and nothing behind it is built. This can be produced in days and put in front of users the same week. Most of the misunderstandings that would have derailed a build surface here.
For questions about feasibility, we build a narrow slice that goes all the way down: real data, real integration, real load. It handles one path and nothing else. If the hard part is going to be hard, it is better to discover it now than in month five.
For questions about demand, the prototype is often barely software. A landing page, a manual process behind it, and a way for people to express intent will tell you more about willingness to pay than a finished product will.
We agree at the start what result would cause the idea to be dropped. If a prototype cannot fail, it is a demonstration, and demonstrations always succeed. Naming the failure condition in advance is what makes the exercise honest.
Prototypes are built to be discarded, and we say so plainly. The code takes shortcuts that would be irresponsible in production, because what you keep from it is the learning. Promoting a prototype to production is how organisations acquire their worst technical debt.
That said, the learning is captured properly. Each prototype ends with a short written account: what we asked, what we did, what happened, and what we recommend. That document is the deliverable.
Where a prototype does justify a build, we start the real build fresh, with what we learned, and throw the prototype away. The architecture is chosen with everything the prototype taught us, which is usually a very different design from the one we would have chosen before.
Guiding teams through transitions and the adoption of new processes.
Most agile adoptions fail quietly. The ceremonies are held, the board is updated, the vocabulary is adopted, and nothing about how decisions get made has changed. We work on the decisions, and let the ceremonies follow from them.
The first weeks are spent watching how the team actually works. We sit in the meetings that already happen, read the tickets, and find out where work actually waits. The bottleneck is rarely where the organisation believes it is, and it is almost never the developers typing more slowly than they could.
Change is introduced one practice at a time, with a reason attached. A team that is told to hold a daily standup will hold one and resent it. A team that agrees it keeps losing a day to blocked work nobody mentioned will hold one and mean it.
We work with the people who will still be there after we leave. Someone inside the organisation needs to own each new practice, or it lasts exactly as long as the engagement does. Identifying and supporting those people is a large part of the work.
Managers get separate attention, because most stalled transitions stall above the team. If a manager still asks when will it be finished about work that was explicitly framed as exploratory, the team will keep giving confident answers and quietly padding them.
Measurement is kept honest. We look at how long work takes from request to production, how much is in progress at once, and how often changes fail. We do not measure output per developer, because that number is easy to improve and means nothing.
When people push back, they usually know something we do not, so we listen. When someone objects to a new practice, they are usually protecting something real that the new practice threatens. Finding out what it is generally produces a better practice than the one proposed.
The engagement ends deliberately, with a written account of what changed, what did not, and what to watch. A coach who becomes permanent has failed. Our aim is a team that can adapt its own process without us.
Orchestration, agents and connectivity.
Language models are useful the moment they stop being a chat window and start being a step inside a process that runs on its own. That is what orchestration means here: a defined sequence, each step with a specific job, checks between them, and a result that lands somewhere a person will actually see it.
Our own product, AITaskManager, is the clearest example. A single instruction produces a branch, an architectural plan, an implementation, a review, fixes, tests, end-to-end checks and a merge. Every step is a separate model call with its own context and its own success condition, and the pipeline stops when a result comes back bad.
Agents are worth using where a task genuinely branches, where the next step depends on what the previous one found. Where the path is fixed, a plain sequence is cheaper, faster and far easier to debug. A large part of our work is telling those two cases apart, because agent frameworks are frequently applied to problems that were never branching to begin with.
Connectivity is where most of the engineering time goes. A model that cannot read your data and cannot write its result anywhere is a demonstration. We connect models to the systems that already run the business: the CRM, the ERP, the ticketing system, the document store, the internal databases.
Every connection is built with explicit permissions and a full audit trail. A model that can write to a production system needs the same controls as a member of staff with the same access, and usually tighter ones. Actions that change data are logged with the input that caused them.
Failure is designed for from the start. Models return malformed output, providers time out, and rate limits arrive at the worst moment. Each step has a defined behaviour when the call fails, so when it degrades, it degrades the way somebody chose.
Costs are visible while the system is being built, not discovered on the first invoice. Each step reports its token use, and we know what a run costs before it is put into daily service. Pipelines that are cheap in testing can be startling at production volume.
We are deliberately unromantic about what this technology does well. It is strong at transforming text, extracting structure from mess, drafting, classifying and summarising. It is weak at arithmetic, at anything requiring a guarantee, and at knowing when it is wrong. Systems are designed around both halves of that.
Grounding models in your knowledge base, with guardrails and local deployment.
Two different things get called training on your own data, and confusing them wastes real money. Retrieval-augmented generation looks your documents up at the moment of the question and gives them to the model as context; your data stays in your database and can be updated or deleted at any time. Fine-tuning changes the model itself so that it adopts a style or a format. Nearly every request we receive for the second is answered better by the first.
Retrieval is the default because it is correctable. When an answer is wrong, you can see which document produced it and fix the document. A fine-tuned model that has absorbed a wrong fact gives no such handle, and correcting it means training again.
Retrieval quality is a search problem more than a model problem. Documents have to be split sensibly, indexed with both meaning and keywords, and re-ranked before anything reaches the model. When a system like this disappoints, retrieval is usually the culprit: it finds the wrong passages and the model answers faithfully from them.
Fine-tuning earns its place for consistent form: a house style, a fixed output structure, a domain vocabulary the base model handles awkwardly. It is a poor way to teach facts, because facts change and models do not update themselves.
Guardrails constrain what the system may do. Inputs are checked before they reach the model, outputs are checked before they reach a person, and anything touching money, contracts or personal data can be routed to a human. Where an answer cannot be grounded in a retrieved source, the honest answer is to say so, even when the model could produce something that reads well.
Evaluation makes the limits measurable. We build a set of test questions with known good answers, drawn from your real material, and run it on every change. Without that, a change that feels like an improvement is indistinguishable from one that quietly degrades a case nobody thought to try.
Where data must not leave the building, we run open-weight models on your own hardware. Llama, Qwen, Mistral and their peers are now good enough for retrieval, classification, extraction and drafting. They are not equal to the largest hosted models at complex reasoning, and we will say plainly when a task is beyond them.
Local deployment is an infrastructure commitment, and we cost it honestly: GPUs, memory, and someone to keep it running. For regulated data or for high steady volume it frequently works out cheaper than per-token pricing. For low or irregular volume it usually does not, and we will say so before you buy hardware.
Finding one repeated process, automating it, and measuring what it saved.
Many organisations know they should be doing something with AI and have no way to decide what. The usual outcome is a pilot with no owner and no measurement, which neither succeeds nor fails and quietly consumes a year. We start from the other end: find the repeated manual work, then ask which tool fits it.
The audit takes two to three weeks. We follow the work itself, sitting with the people doing it and counting what eats their time. Document handling, support triage and recurring reporting come up most often, but the specifics differ enough that it pays to look before deciding.
Each candidate is scored on volume, how much a mistake would cost, and how well the current process is defined. High volume and a low cost of error make a good first target. Anything where an error is expensive stays with a person in the loop, at least until the measurements justify otherwise.
Then we pick exactly one and build it properly. A single working case, with real numbers attached, does more for adoption inside a company than five simultaneous pilots that all remain in progress.
Before anything is built, we measure the current process: how long it takes, how often it goes wrong, how much it costs. Without a baseline there is no way to demonstrate a result afterwards, and every subsequent conversation becomes a matter of opinion.
After it is running, we measure again, in the same terms. Sometimes the saving is smaller than hoped, and we say so. A measured modest result is worth considerably more to a business than an unmeasured impressive one, because it can be extrapolated with confidence.
The people whose work is affected are involved from the first week. They know where the exceptions hide, and they are the ones who will decide whether the system is used or worked around. A tool imposed on a team is abandoned within a month of the project ending.
Only after the first case has held up in production do we discuss the second. By then the organisation has a real reference point for what these systems cost, what they save, and where they need supervision, and the second decision rests on numbers.
Cost, quality, availability and auditability after launch.
An AI feature needs looking after once it is live. Providers change models underneath you, costs drift as usage grows, and answer quality degrades in ways no exception is ever raised for. This is where the AI projects that quietly disappear tend to disappear, usually about six months in.
Cost is watched continuously and attributed to the part of the business generating it. Token spend is reported per feature and per department, with a budget and an alert. A single badly formed prompt loop can multiply a monthly bill, and you want to catch it the same day.
Quality is tracked against a fixed set of reference cases that runs on a schedule. We measure factual accuracy against known answers, consistency of tone, and the rate at which the system asserts things it cannot support. The trend matters more than any single figure, because it shows drift that a spot check cannot.
Providers fail. When a call times out or a rate limit is hit, traffic moves to a secondary provider or to a local open-weight model automatically. Which fallback is appropriate depends on the feature: a draft can degrade to a smaller model, while an extraction that feeds a financial system should stop and queue instead.
The application talks to a thin layer of our own, and that layer talks to the provider. Swapping the model behind a feature is then a configuration change. Given how quickly this field moves, an application wired directly into one vendor is a maintenance liability from the day it launches.
New models are evaluated against the same reference set before they are adopted. A newer model can still be worse at your particular task, and a swap can break a case that worked for a year. The evaluation makes that visible before your users find it.
Every exchange is logged: the input, the retrieved context, the model, the version, the output and the cost. This is what makes it possible to answer why the system said that three months later. Under the EU AI Act it is also increasingly what you are obliged to be able to produce.
Someone is on call, and the runbook says what to do. Which provider to switch to, how to disable a feature without taking down the application, whom to notify. Most AI incidents are quiet: a slow degradation nobody owned. Ownership is the point of this work.
We aspire to live up to the agile principles and values as outlined in the Agile manifesto, in order to deliver products, with both value and quality.
TC Dev is made up of a team of IT professionals who are passionate about providing the best software development solutions to their clients. Each member brings a unique perspective and skill, allowing for a more holistic approach to problem-solving and broader range of strategies to be considered. One of the defining characteristics of a strong team is a shared goal and vision. and at TC Dev, everyone in the team understands and aligns with the goals, fostering a sense of collective ownership.
The company was founded by Ondřej Trochta and Paula Costa after having successfully worked together on an industrial automation project. Their individual skills, interests, perspectives and commitment to fostering a healthy, communicative and collaborative team environment, planted the seed that led to the creation of an organisation that does just that. A strong team is the cornerstone of business success and successful teams enable maximum productivity, drive innovation and nurture a positive company culture.
“That describes us in a nutshell.”
For bigger projects, we have a our own talent pool of IT specialists that are located both within and outside of Czechia. We believe that great work can be done from anywhere with great people! A good team brings individuals together to work towards the organization's collective goals productively and efficiently. Working in a group, sharing knowledge and ideas and understanding how different employees perform leads to innovation and greater efficiency. For this reason we have our team working from anywhere they call home. We understand that for great work to happen there must be adequate rest and comfort and so we provide our team with the opportunity to be more comfortable, motivated and focused in order to fully meet our quality goals
We are a small group of people who build with AI. The models take the repetitive part of the work, so a product goes from an idea to a running system in weeks instead of quarters, and the time we save goes into the parts that have to be right.
Speed and reliability are the same goal here: each round sharpens software that is already in use, without throwing it away. We take on the whole path, from the first conversation through architecture, code and testing to deployment.
If you have a project in mind, write to us and we will talk about what is possible.
Send us a note and we will come back to you with the questions we would ask on a first call.
info@tcdev.czTC Dev takes on development work: software built from scratch, existing systems extended, and manual routines turned into something that runs by itself. If any of that matches your situation, a short call is the quickest way to find out whether we fit.
Web applications, internal tools, APIs and integrations, from the first sketch to running in production.
Repeated manual work — data carried between systems, reports assembled by hand, approvals chased over email — handed over to something that runs on its own.
Assistants, document processing and private models, wired into the systems you already use.
An unfinished or inherited codebase reviewed, stabilised and carried forward.
You do not need a specification or a fixed budget to start. Tell us what the software should do and who will use it, leave an email or a phone number, and we come back with a plan, a rough cost and the first steps. If it is easier to talk it through, book a call below.
Thirty or sixty minutes, whichever suits. Times that are already taken are not offered.
Monday to Friday, 9:00–17:00 Prague time, up to a week ahead. Only free times are shown; anything already in the calendar simply is not there.
The time is held for you. Open the message we just sent to and follow the link in it — that confirms the meeting and puts it in the calendar. The slot is held for .