[{"data":1,"prerenderedAt":239},["ShallowReactive",2],{"index-page":3,"landing-blog-posts":142},{"id":4,"title":5,"about":6,"blog":9,"body":12,"description":12,"extension":13,"faq":14,"hero":45,"meta":72,"navigation":73,"path":74,"principles":75,"seo":90,"services":91,"stem":140,"__hash__":141},"index\u002Findex.yml","",{"title":7,"description":8},"Built on clear ownership","RIVER DATA is a software development and digital transformation provider based in the Czech Republic, founded by Radek Rezac. We believe the future is built on AI and strengthened by trust.",{"title":10,"description":11},"Notes on delivery","Short, practical writing on ownership, architecture, and AI that holds up under daily use.",null,"yml",{"title":15,"description":16,"categories":17},"Questions we hear often","Straight answers about how RIVER DATA scopes, delivers, and hands over work.",[18,27,36],{"title":19,"questions":20},"Working with RIVER DATA",[21,24],{"label":22,"content":23},"What does RIVER DATA actually build?","Enterprise software: web applications, internal tools, APIs, integrations, and cloud services. We also modernize existing systems and add practical AI where it earns its place.",{"label":25,"content":26},"Can RIVER DATA join an existing team?","Yes. Full IT outsourcing means dedicated engineers or a managed team that takes clear ownership of delivery, not just a set of tickets.",{"title":28,"questions":29},"Delivery and ownership",[30,33],{"label":31,"content":32},"How does RIVER DATA approach delivery?","Every feature gets a purpose, an owner, and a release path before work starts. That is what keeps delivery discipline intact as a project grows.",{"label":34,"content":35},"What happens with legacy systems?","We start with an assessment of what carries technical debt and what needs a migration plan. Modernization follows that plan instead of a blanket rewrite.",{"title":37,"questions":38},"AI and security",[39,42],{"label":40,"content":41},"How does RIVER DATA use AI in practice?","We keep AI features as simple as the workflow they support, then put the effort into making them reliable enough for daily use, with human review where it matters.",{"label":43,"content":44},"How is security handled?","Access controls, audit trails, monitoring, and incident response are part of the delivery model from the start, alongside documentation that supports adoption.",{"title":46,"description":47,"links":48,"images":59},"Secure intelligence. Smarter solutions. Better companies.","We build, modernize, and scale enterprise software. From AI solutions to full IT outsourcing, our engineers ship faster with AI-augmented development.",[49,55],{"label":50,"to":51,"color":52,"variant":53,"icon":54},"See our scope","\u002Fwork","primary","solid","i-lucide-arrow-right",{"label":56,"to":57,"variant":58},"Start a conversation","\u002Fcontact","outline",[60,63,66,69],{"src":61,"alt":62},"\u002Fimages\u002Friverdata.png","The RIVER DATA mark, a teal infinity loop, above the company wordmark",{"src":64,"alt":65},"\u002Fimages\u002Fmvp-development.png","An engineer working through MVP development, product launch, and iteration stages across layered screens",{"src":67,"alt":68},"\u002Fimages\u002Fdedicated-team.png","Three team members reviewing work together around laptops in an office",{"src":70,"alt":71},"\u002Fimages\u002Fstaff-augmentation.png","A hand connecting a networked globe to a networked mind, representing distributed engineering capacity",{},true,"\u002F",{"title":76,"description":77,"items":78},"How we think about delivery","A few lines that describe how RIVER DATA approaches software delivery, in practice.",[79,82,84,86,88],{"quote":80,"source":81},"Good software delivery starts with clear ownership. When every feature has a purpose, an owner, and a release path, the meeting gets quieter in the best way.","RIVER DATA",{"quote":83,"source":81},"Built for the next twenty years of business, not the next trend.",{"quote":85,"source":81},"The release path is clear before the first sprint starts, so the team knows what is being built, who owns it, and how it will be supported.",{"quote":87,"source":81},"We kept the AI feature simple because the workflow was simple. The hard work was making it reliable enough for daily use.",{"quote":89,"source":81},"This platform needed less noise and more ownership, so every service now has a purpose, an owner, and a clear path to change.",{},{"title":92,"description":93,"items":94},"RIVER DATA scope","Five service domains, each grounded in ownership, security, and maintainable delivery.",[95,104,113,122,131],{"title":96,"description":97,"icon":98,"scope":99},"Software development","Web applications, internal tools, APIs, integrations, cloud services, and product engineering.","i-lucide-code",[100,101,102,103],"Web applications","Internal tools and APIs","Cloud services","Product engineering",{"title":105,"description":106,"icon":107,"scope":108},"Modernization","Legacy system assessment, technical debt reduction, architecture cleanup, migration planning, and maintainability.","i-lucide-refresh-cw",[109,110,111,112],"Legacy system assessment","Technical debt reduction","Architecture cleanup","Migration planning",{"title":114,"description":115,"icon":116,"scope":117},"AI solutions","Practical AI features, assistants, automation, retrieval workflows, evaluation, and human review loops.","i-lucide-sparkles",[118,119,120,121],"Practical AI features","Assistants and automation","Retrieval workflows","Evaluation and human review",{"title":123,"description":124,"icon":125,"scope":126},"IT outsourcing","Dedicated engineers, managed teams, delivery ownership, quality practices, and transparent collaboration.","i-lucide-users",[127,128,129,130],"Dedicated engineers","Managed teams","Delivery ownership","Transparent collaboration",{"title":132,"description":133,"icon":134,"scope":135},"Security and operations","Access controls, audit trails, monitoring, incident response, documentation, and adoption support.","i-lucide-shield-check",[136,137,138,139],"Access controls and audit trails","Monitoring and incident response","Documentation","Adoption support","index","mm3JAtNEXcNGrDBDo3SlqtlCMB3kMWMP5N8p8QE5QSw",[143,179,210],{"id":144,"title":145,"author":146,"body":149,"date":170,"description":171,"extension":172,"image":70,"meta":173,"minRead":174,"navigation":73,"path":175,"seo":176,"stem":177,"__hash__":178},"blog\u002Fblog\u002Fkeeping-ai-features-simple-enough-to-trust.md","Keeping AI features simple enough to trust",{"name":147,"role":148},"Radek Rezac","Founder, RIVER DATA",{"type":150,"value":151,"toc":167},"minimark",[152,155,158,161,164],[153,154,87],"p",{},[153,156,157],{},"That is the pattern we see across most practical AI work. The interesting engineering problem is rarely the model itself. It is the retrieval step that feeds it, the evaluation loop that catches when it drifts, and the human review point that exists for the cases where a person still needs to decide.",[153,159,160],{},"A team we worked with needed less noise and more ownership. Every service, including the AI parts, now has a purpose, an owner, and a clear path to change. That ownership rule does not stop at traditional code. An AI feature without a named owner tends to degrade quietly until someone notices the wrong answer in production.",[153,162,163],{},"This is also where security and operations meet AI solutions directly. Access controls, audit trails, and monitoring matter as much for an AI assistant as for any other system that touches real data. Treating it as a special case, exempt from the usual review, is how avoidable mistakes happen.",[153,165,166],{},"Practical AI earns its place by being dependable first. Everything else is secondary.",{"title":5,"searchDepth":168,"depth":168,"links":169},2,[],"2026-06-24","Why the hardest part of a practical AI feature is reliability, not the model.","md",{},4,"\u002Fblog\u002Fkeeping-ai-features-simple-enough-to-trust",{"title":145,"description":171},"blog\u002Fkeeping-ai-features-simple-enough-to-trust","xjXpv5vFsMqjU7w7f4RYHNEaLbHFw24O_8Op9anFPpE",{"id":180,"title":181,"author":182,"body":183,"date":202,"description":203,"extension":172,"image":64,"meta":204,"minRead":205,"navigation":73,"path":206,"seo":207,"stem":208,"__hash__":209},"blog\u002Fblog\u002Fbuilt-for-the-next-twenty-years.md","Built for the next twenty years of business, not the next trend",{"name":147,"role":148},{"type":150,"value":184,"toc":200},[185,188,191,194,197],[153,186,187],{},"Built for the next twenty years of business, not the next trend. It is easy to agree with that line and still make decisions that work against it.",[153,189,190],{},"Every year brings a new framework, a new pattern, a new tool that claims to remove some category of pain. Some of it is genuinely useful. Most of it adds a dependency that someone will need to understand, maintain, and eventually replace, long after the person who chose it has moved on.",[153,192,193],{},"The way we evaluate a technology choice is to ask who will own it in three years, and whether that person will thank us or curse us. Reliable architecture is not glamorous. It is the codebase a new engineer can read on their second day, the integration that fails loudly instead of silently, the migration plan written down instead of remembered.",[153,195,196],{},"None of this means avoiding change. Legacy systems need modernization, and some technical debt has to be paid down before it compounds. The difference is choosing changes because they reduce risk and improve maintainability, not because a tool is new.",[153,198,199],{},"Software that teams can trust looks unremarkable from the outside. That is usually a sign it was built correctly.",{"title":5,"searchDepth":168,"depth":168,"links":201},[],"2026-06-02","A practical case for choosing maintainable architecture over whatever framework is loudest this quarter.",{},5,"\u002Fblog\u002Fbuilt-for-the-next-twenty-years",{"title":181,"description":203},"blog\u002Fbuilt-for-the-next-twenty-years","GYs0ZRoAN2c7xJXvKR-p9o2KEfM3s-u9005Q98wAjAc",{"id":211,"title":212,"author":213,"body":214,"date":232,"description":233,"extension":172,"image":67,"meta":234,"minRead":174,"navigation":73,"path":235,"seo":236,"stem":237,"__hash__":238},"blog\u002Fblog\u002Fclear-ownership-quieter-meetings.md","Clear ownership makes for quieter meetings",{"name":147,"role":148},{"type":150,"value":215,"toc":230},[216,218,221,224,227],[153,217,80],{},[153,219,220],{},"That quiet is not a symptom of low ambition. It is what happens when a team stops re-litigating who is responsible for what. A status meeting where the assignment is already settled needs less time and produces fewer surprises later.",[153,222,223],{},"In practice, we ask three questions before a feature moves into a sprint. What is it for. Who owns it end to end. How will it be supported once it ships. If any of those three cannot be answered plainly, the feature is not ready yet, no matter how appealing the idea is.",[153,225,226],{},"This applies just as much to modernization work as to new product features. A legacy system rarely has a single owner. Part of an assessment is figuring out where ownership has quietly disappeared, and putting it back before the technical work starts.",[153,228,229],{},"The payoff shows up later, when a release goes out and nobody has to guess who to call. That is delivery discipline in a sentence: not more process, just less ambiguity about who is accountable for what.",{"title":5,"searchDepth":168,"depth":168,"links":231},[],"2026-05-12","Why naming an owner and a release path for every feature changes how a delivery meeting actually feels.",{},"\u002Fblog\u002Fclear-ownership-quieter-meetings",{"title":212,"description":233},"blog\u002Fclear-ownership-quieter-meetings","HfA8AQPnFOMZVZeZYKTadzk6nelLHozHhagVEKAU54k",1785537448648]