# BRACKETS — Full Content > Clarity in what to build. Quality in what we ship. This document concatenates the full content of every public page on the website. It is intended for use by large language models and other AI agents that benefit from grounded, structured context. A shorter index is available at /llms.txt. ## About BRACKETS is a digital product studio based in Bratislava, Slovakia. We help companies find clarity in what to build and deliver it as high-quality digital products through product discovery, design, engineering, and AI integration. We work with clients across healthcare, fintech, e-commerce and enterprise — from early-stage discovery and MVPs through long-term ownership of mission-critical software. Our model combines hands-on delivery with fractional technical leadership. ### Key facts - Name: BRACKETS - Legal name: BRACKETS by TRIAD s.r.o. - Headquarters: Brigadnicka 27, 841 10, Bratislava, SK - Area served: Worldwide - Areas of expertise: Product discovery, Product design, UX and UI design, Web and mobile engineering, AI integration, Fractional CTO, Software ownership and SLA, Workflow and process digitization - Email: connect@meetbrackets.com - Phone: +421910120009 - LinkedIn: https://www.linkedin.com/company/brackets-by-triad - Website: https://meetbrackets.com --- ## Homepage URL: https://meetbrackets.com/ > We're an AI-accelerated product studio. We help you figure out what's worth building, then build it right. We've shipped 80+ projects over the past decade. Headline: The code is easy. The thinking isn't. --- # Services ## AI & Agentic Engineering URL: https://meetbrackets.com/accelerate > AI is both how we build and what we build. We use agents in delivery, with senior engineers owning architecture and review. And we build AI into the products we ship for clients: assistants, [computer vision](https://meetbrackets.com/case-studies/ai-running-technique-analysis), intelligent workflows. ### Our stance ##### AI is a tool, not a strategy AI doesn't replace engineers. It gives [experienced engineers leverage](https://meetbrackets.com/thinking/i-dont-write-code-anymore) they didn't have before. We've built our delivery around that leverage: agents handling code, tests, documentation, and edge-case surfacing, while senior engineers own architecture, review, and what ships. The result is a delivery rhythm that wasn't possible two years ago, and is getting faster as the tools improve. We don't sell AI as magic. We sell clarity, and software that holds up in production. ### What we do - **Agentic Engineering** — We use AI agents across code generation, code review, testing, security and documentation. Every project benefits. - **AI Features for Clients** — Chatbots, smart assistants, recommendation engines, intelligent search, document processing, content generation: built as features inside your product. - **Workflow Automation** — Building architectures of agents with custom integrations to automate repetitive business processes. ROI often in months. - **EU-Compliant AI** — GDPR and EU AI Act considerations built in from the start. Data sovereignty, model transparency, and audit trails designed into the architecture. ### Who this is for 1. Companies that want AI features in their product. Done practically, not as a demo. 2. Teams drowning in repetitive manual processes that could be automated. 3. Organizations that need EU-compliant AI integration. 4. Leaders who want an honest assessment of where AI helps and where it doesn't. ### What we don't do ##### We don't sell AI as magic We don't promise 10× results. We don't build AI solutions looking for a problem. If your challenge is better solved with a spreadsheet and a clear process, we'll tell you that — and save you six months of AI experimentation. ### Common questions **Q: What's agentic engineering, and how is it different from vibe coding?** Vibe coding is generating code with an AI and hoping it works. [Agentic engineering is using AI agents as serious engineering tools](https://meetbrackets.com/thinking/vibe-coding-vs-agentic-engineering-what-actually-changes-when-you-ship), with senior review, architecture decisions, and quality controls. The first is fast and brittle. The second is fast, production-ready and stays sustainable for years. We do the second. **Q: Do you build AI products or use AI internally?** Both. We use AI tools daily in our engineering workflow, and we build AI-powered features into client products: chatbots, assistants, recommendation engines, document processing, workflow automations, and more. **Q: What models and tools do you use?** We use models from Anthropic, OpenAI, ElevenLabs, and open-source providers. For orchestration and automation: n8n, Claude Agents and custom integrations. Whatever fits the use case. We're model-agnostic and tool-pragmatic. **Q: Can you work with our existing data?** Yes. We typically start with your existing data and build AI features on top of it. We focus on practical applications, not moonshot R&D. **Q: Is it EU-compliant?** We design for GDPR and the EU AI Act from the start. Data stays in EU-hosted infrastructure unless you explicitly decide otherwise. **Q: What if AI isn't the right solution?** We'll tell you. Honestly, most problems don't need AI. They need better processes or simpler automation. We recommend AI only when it genuinely earns its complexity. --- ## Build and Delivery URL: https://meetbrackets.com/build > You get a team that owns the outcome. Not a collection of contractors who write code and disappear. Every project gets a PM, designer, architect, and senior engineers. ### What we build - Web applications & platforms - Multi-tenant SaaS systems - APIs & third-party integrations - Reservation systems - Mobile apps (iOS, Android, cross-platform) - Product configurators - Internal tools & admin dashboards - E-learning & content platforms - AI workflow automations ### How we deliver - **Dedicated Teams** — PM + designer + architect + developers + QA. One team, one mission. Not a revolving door of freelancers. - **Predictable Cadence** — Two-week sprints, weekly demos, monthly retrospectives. You always know where things stand. - **Transparent Communication** — Direct Slack access to your team. No account managers filtering information. Ask anything, anytime. - **Quality by Design** — Code reviews, automated testing, CI/CD pipelines, monitoring. Built in from day one, not bolted on later. ### What this looks like in practice ### Common questions **Q: What technologies do you use?** React, Next.js, Laravel, React Native. Chosen per project, not per hype cycle. AI-writes code, humans architect and review. **Q: How large are your teams?** Typically 3–8 people: PM, designer, architect, 2–4 developers, and QA. Scaled to the project, not to the budget. **Q: Can you take over an existing codebase?** Yes, but we'll audit it first. We need to understand what we're inheriting before we commit to it. **Q: How do you handle communication?** Weekly demos, async updates, direct access to your team. No layers of account managers between you and the people doing the work. **Q: What does ongoing support look like?** We offer retainer-based support for launched products — monitoring, bug fixes, incremental improvements, and scaling. --- ## Fractional Leadership URL: https://meetbrackets.com/lead > Not every company needs a full-time CTO. But every company making technology decisions needs someone who's done it before. We provide senior technical leadership on a fractional basis. ### When you need this 1. #### Scaling Without a CTO Your company is growing, technical decisions are getting complex, but you're not ready for a CTO's full-time hire. A fractional CTO bridges the gap. Before a Big Build. 2. #### Before a Big Build You're about to invest significantly in software. You need someone to validate the technical approach, challenge the vendor, and ensure the architecture will hold. 3. #### Second Opinion Your existing technical direction feels wrong but you can't articulate why. An experienced outside perspective often reveals the real issue in days, not months. ### What we offer - **Fractional CTO** — Embedded technical leadership — architecture decisions, team management, vendor evaluation, technology strategy. 1–3 days per week. - **Architecture Audits** — Deep review of your existing system — scalability, security, maintainability, technical debt. Honest assessment with actionable recommendations. - **Technical Advisory** — Ongoing access to senior technical expertise — on-demand guidance for specific decisions, without the embedded commitment. ### How engagements work ### Who this is for 1. Startups without technical co-founders who need experienced leadership. 2. Growing companies where tech decisions are outpacing the team's experience. 3. Enterprises needing an external perspective to challenge internal assumptions. 4. Boards or investors who want independent technical due diligence. ### Common questions **Q: What's the difference between fractional CTO and consulting?** A consultant gives advice and leaves. A fractional CTO is embedded — attending your standups, reviewing your architecture, mentoring your team. We own outcomes, not just recommendations. **Q: How much time does a fractional CTO spend with us?** Typically 1–2 days per week, depending on the engagement. Enough to drive decisions, not so much that it replaces a full-time hire. **Q: When should we hire a real CTO instead?** When you've validated your product-market fit, have 5+ engineers, and need someone full-time. Until then, fractional makes more sense financially and strategically. **Q: Can you help us hire a permanent CTO?** Yes. We often help define the role, interview candidates, and ensure a smooth transition. We'd rather help you outgrow us than create dependency. **Q: Do you also build, or just advise?** We can do both. Some engagements are advisory only. Others combine leadership with hands-on delivery through our team. --- ## Own Your Software URL: https://meetbrackets.com/own > Juggling spreadsheets and tools that don't quite fit your business? At some point, building your own becomes the smarter investment. We help you figure out when, and then we build it. ### The "SaaS tax" ##### No SaaS tool ever fits exactly. You pay the gap somewhere, usually in three forms at once: 1. **In money.** You pay full price for software you use 60% of. The other 40% gets absorbed by spreadsheets and workarounds. 2. **In workarounds.** Senior people doing junior work because the tool can't model what actually happens. None of it shows up on an invoice. 3. **In time.** Onboarding doubles because new hires learn the tool and the workarounds. Data lives in three places, so decisions wait. Most companies absorb all three quietly. Eventually one gets too expensive to ignore. ### Why now Custom software used to mean six-figure budgets and 12-month timelines. That kept it locked to enterprises, while everyone else had to go with SaaS. AI moved that math. The systems we used to reserve for enterprises now work for mid-market operations and small businesses with clear processes. - **2–3 years** — Typical breakeven - **0€** — Per-seat fees - **100%** — Feature fit ### What we build - **SaaS Replacements** — Custom platforms that replace expensive, ill-fitting SaaS tools. Built to your exact workflow, integrated with the tools you want to keep. - **Internal Platforms** — Operations tools, admin dashboards, reporting systems. Software that makes your team faster and removes manual work. - **Micro-SaaS** — Focused, single-purpose tools that solve one problem well. Sometimes these become products of their own. - **Legacy Modernization** — Replacing outdated systems with modern, maintainable software — without the big-bang rewrite risk. ### Who this is for 1. Companies whose work doesn't fit any SaaS. Compliance edges, hybrid workflows, industry-specific operations, etc. 2. Operations teams drowning in workarounds, spreadsheets and manual processes. 3. Mid-market organizations spending €10k+/year on SaaS that covers less than 70% of their needs. 4. Smaller companies who couldn't afford custom three years ago and can now. The minimum viable project size moved. ### What this looks like in practice Dr.Max didn't come to us with a SaaS to replace. They came with a process the market hadn't built a tool for. Every month, two people spent three days producing the marketing leaflet: exporting product data from the sales team's tool, dropping it into spreadsheets, chasing external vendors and designers by email, reconciling versions, then doing it all again 30 days later. Six person-days of manual coordination, every month, on a workflow nobody had thought of as "a system." So we built one. They hadn't come looking for custom software, just for someone who could help with a process that hurt. Three years ago, building bespoke software for a single internal workflow would have been an absurd answer at the budget and timeline they had. AI moved both. We delivered the system in under two months. Not every custom build replaces an existing tool. Some of them replace assumptions about what you have to live with. Both count. ### Common questions **Q: How do I know if custom software is worth it for us?** Two questions to start with. First, how much of your day is spent working around a tool? If the answer is "a lot," the fit conversation is worth having regardless of price. Second, are you spending €10k+/year on SaaS that covers less than 70% of your needs? If yes, the cost math is probably already in your favor. **Q: How does a SaaS replacement actually work in practice?** It's almost never a big-bang switch. We start by mapping which parts of the SaaS you actually use, which parts you work around, and which parts the tool does that nobody on your team relies on anymore. Then we build the highest-impact module first, usually the workflow costing you the most in time or workarounds, and run it alongside the old tool. Then we continue in phases. **Q: How long does this take?** A typical SaaS replacement runs 2–6 months depending on complexity. We start with the highest-impact module rather than rewriting everything at once. You see real value inside the first quarter. **Q: Isn't custom software expensive to maintain?** You own the code. We offer ongoing support retainers, or you can bring it in-house. Either way, you're not locked in. **Q: Can you migrate our existing data?** Yes. Data migration is part of every replacement project. We plan it early and test it thoroughly. **Q: What if we only need to replace part of our stack?** That's actually the most common scenario. We build the custom piece and integrate it with the SaaS tools you want to keep. --- ## Product and Discovery URL: https://meetbrackets.com/think > Most failed projects fail not because the code is bad, but because the scope was wrong. We help you figure out what to build before a single line of code is written. ### Let's think about the problem first ##### Companies come to us with "we need an app." But the app isn't the problem. The problem is that nobody has asked the hard questions yet: Who is this really for? What does success look like? What should we explicitly not build? Most agencies will happily quote your brief. We'd rather challenge it. Because the most expensive feature is the one you build and nobody uses. ### What we actually do - **Clarity Sessions** — Structured workshops that turn vague ideas into clear product direction. We challenge assumptions, map stakeholders, and define what success looks like. - **Discovery Sprints** — 2–4 week intensive engagements where we research, prototype, and validate before you commit to a full build. Think of it as insurance against building the wrong thing. - **Scope Shaping** — We take your feature wishlist and turn it into a pragmatic roadmap. What's MVP? What's phase 2? What should you never build? - **Technical Blueprints** — Architecture decisions, technology choices, integration mapping — all documented and explained in plain language. ### How a typical engagement works ### Who this is for 1. Companies with the idea or vision, but lacking clarity and priorities 2. Products that are stuck, growing complexity or unclear direction. 3. Teams preparing a big investment who want a second opinion. 4. Founders who need technical leadership before they hire a CTO. ### Common questions **Q: How long does a discovery sprint take?** Typically 2–4 weeks depending on complexity. We'll shape the timeline during our initial conversation. **Q: What do we get at the end?** A clear product brief, validated scope, technical architecture, and a realistic plan to move forward. Or a clear reason not to. **Q: Do we need a technical team?** No. We bring the technical expertise. You bring the domain knowledge and business context. **Q: Can you also build what we discover?** Yes. Most of our discovery engagements evolve into full build partnerships. **Q: What if we already have a product that's stuck?** We run the same clarity process. Often the product isn't stuck, the scope is. --- # Company ## Who we are URL: https://meetbrackets.com/about > We’re BRACKETS, a 20-person digital product studio from Bratislava with a decade of building behind us. We help companies figure out what’s worth building, then build it right. We use AI everywhere. But the thinking still happens between humans. #### We started by solving problems no one else wanted to own. BRACKETS began as a small dev team working with companies who needed more than code — they needed someone to think with them. Over the years, that mindset led to two standalone SaaS products: Kontentino and Allfred. Both were built inside the studio and spun off into their own companies. That experience — building, launching, and scaling our own products — shaped how we work with clients today. We don't just deliver. We think about what's worth delivering in the first place. > {% smallText %}— Two SaaS spin-offs. One of them now serves 5,000+ teams globally.{% /smallText %} ##### [See our work](/case-studies) #### We staff teams, not seats. Every project gets a PM, a designer, and an architect. Not a rotating cast of juniors. You get a team that owns the outcome — and that you don't need to babysit. Our average project tenure is 14 months. Clients stay because the team delivers. #### The code is easy. The thinking isn't. We don't start with sprints. We start with clarity — what problem are we actually solving, and is building software the right answer? We kill bad ideas early, shape scope ruthlessly, and only write code when we know it matters. > {% smallText %}— Not a process diagram. These are the principles that shape every project we take on.{% /smallText %} ##### [How we think](/approach) ### What working with us looks like - **10+ years** — In the game since 2015. - **20 specialists** — Senior-heavy team that stays. - **ISO certified** — ISO 9001 & 27001. - Member of Devin Band - Kontentino - Allfred - TRIAD --- ## How we think URL: https://meetbrackets.com/approach > Curiosity, not process. These are the principles that shape every project we take on, and every one we turn down. #### Our curiosity drives our questions Most agencies will happily quote what you wrote down. We'd rather understand it first. Who is this for, what would success actually look like, what should we deliberately leave out. Those questions don't get asked enough, so we ask them before anyone touches code. The most expensive feature is the one nobody uses. > {% smallText %}— {% /smallText %}*With EANM, the first decision was what to strip away, not what to add.* ##### [Product & Discovery](/think) #### We staff teams, not seats. Every project gets a PM, a designer, and an architect. Not a rotating cast of juniors. You get a team that owns the outcome. And that you don't need to babysit. > {% smallText %}— Our average project tenure is 14 months. Clients stay because the team delivers.{% /smallText %} ##### [Build & Delivery](/build) #### We replace SaaS where it makes sense Legacy spreadsheets and SaaS tools that don't quite fit your business? At some point, building your own software that perfectly fits your needs becomes the smarter investment. We help you figure out when, and then we build it. > {% smallText %}— {% /smallText %}*Dr.Max* ##### [Own Your Software](https://meetbrackets.com/own) #### AI as a new standard We use AI agents everywhere in delivery, with senior engineers owning architecture and review. Also, we build AI into the products we ship for clients: assistants, computer vision, intelligent workflows. We use it daily. We don't pretend it's magic. > {% smallText %}— {% /smallText %}*Runology's AI running technique video analysis is one example we shipped.* ##### [AI & Modern Tech](/accelerate) #### We stay until it works. Long-term partnerships, not project-and-run. We evolve systems, not just deliver them. Most of our clients have been with us for 3+ years. Some since the beginning. > {% smallText %}— IKEA, Mavie, EANM — all multi-year relationships where we grew the product alongside the business.{% /smallText %} ##### [See our work](/case-studies) #### We've done this before. With our own products. Kontentino and Allfred started inside BRACKETS. We know what it takes to go from a prototype to a real company. That changes how we advise clients — because we've felt the same pressure. > {% smallText %}— Two SaaS spin-offs. One of them now serves 5,000+ teams globally.{% /smallText %} ##### [About us](/about) --- ## Is your vibe-coded software ready for production? URL: https://meetbrackets.com/audit-your-vibe-coded-software > It shipped fast and it works. Our free audit tells you whether it holds as you grow. ### What it is #### An audit of vibe-coded software is a structured read of code your team generated fast: what it actually does, where it is thin, and what it takes to run it for years. Generated code is not worse code. It is code nobody had to reason through line by line, so the system exists while the thinking behind it was never written down. That gap is what [changes the moment you ship it](/thinking/vibe-coding-vs-agentic-engineering-what-actually-changes-when-you-ship). ### Why it breaks in production ##### The code is there. The context is not. A product built this way usually runs fine until it meets real users, real data and a second developer. Then the questions start: which parts are load-bearing, why does the same logic exist in three places, what happens when this dependency stops being maintained, and who decided how sessions and permissions work. The answers are recoverable, but only by reading the system properly. The same tools that generated the code are good at reading it back, which is how we [work with AI every day](/accelerate). ### How we read an AI-generated codebase ### What you walk away with - **An Inventory You Can Trust** — What the product is actually made of, which parts carry the load, and where the same logic was generated more than once. - **The Risks That Matter** — Authentication, data handling, [dependencies](/audit-your-vibe-coded-software/dependency-risk) and failure paths, reviewed and ranked: what is urgent, what can wait, what is fine as it is. - **What Is Really Verified** — An honest read of [test coverage](/audit-your-vibe-coded-software/test-coverage), so you know which behaviour is protected and which only looks protected. - **A Fix-First Shortlist** — A plan in the order it should happen, with effort and impact for each item, so the next sprint is a decision instead of a guess. ### How we work in practice ### Common questions **Q: Is vibe-coded software a bad thing?** No. It is how a lot of good products now start, and getting to something real quickly is an advantage. The audit exists to tell you whether what you built can carry the next stage, not to judge how it was written. **Q: We have no tests and no documentation. Is that a problem?** It is normal for software built this way, and it does not block the audit. We read the code itself and write down how the system actually behaves, which is usually the first documentation the product has ever had. **Q: Will you tell us to throw it away and start over?** Only if the evidence points there, and it rarely does. Most products built this way need targeted repair in a few specific places, not a rewrite. We tell you honestly either way. **Q: Who sees our code?** Only BRACKETS engineers and the AI coding assistants they use while doing the audit, which are Anthropic services on business plans that do not train on your code. Access is read-only, and you can remove our access at any time. --- ## We hire right URL: https://meetbrackets.com/careers > 20-person product studio from Bratislava. Clear thinking, pragmatic AI, zero drama. #### Small team. Big ownership. No one looking over your shoulder. We're not a factory. There's no assembly line, no ticket-punching, no "just do what the spec says." People here own problems end-to-end — from understanding what a client actually needs to shipping something that works and lasts. We run on trust, not control. Meetings exist only when they're useful. Slack is async-first. Nobody tracks your hours — we track outcomes. The team is senior enough that nobody needs to be managed, and experienced enough to know when to ask for help. We've been around for over a decade. Two SaaS products — Kontentino and Allfred — were born inside BRACKETS and spun off into standalone companies. That's the kind of environment this is: people build real things here, and some of those things outgrow the studio. > {% smallText %}— "Our standups are so short, the coffee doesn't even get cold." — Actual internal Slack message, probably{% /smallText %} #### What we actually care about (not what fits on a poster). - **Think first, build second** — We don't jump into code. We ask hard questions, challenge assumptions, and figure out what's actually worth building. Clarity beats speed every time. - **Own the outcome** — Nobody here says "that's not my job." If you're on a project, you care about the whole thing — not just your corner of it. - **Drama-free delivery** — We don't do panic mode. Predictable, calm, reliable work. Clients say they don't need to babysit us. That's the standard. - **AI as a tool, not a religion** — We use AI daily — in code, research, testing, docs. But we don't pretend it replaces thinking. It makes good people faster, not average people good. - **Say what you think** — Disagreement is welcome. Silence isn't. The best ideas here come from people who speak up — including when they think something won't work. - **12+ years** — In business since 2013. - **~20 people** — Small enough to know everyone. - **2 SaaS spin-offs** — Kontentino & Allfred — built internally. - **10+ countries** — Clients across the EU. - **12+ months** — Average project length. - **ISO 9001 & 27001** — Certified quality & security. #### What you get (besides interesting work) We don't do ping-pong tables and unlimited snacks. We do things that actually make your work life better. 1. Flexible hours 2. Remote-friendly 3. Async-first communication 4. MacBook or equivalent 5. Conference budget 6. Learning resources 7. Work on real products, not just client projects 8. AI tools & subscriptions 9. Extra vacation days 10. No crunch culture 11. Bratislava office (optional) 12. Team retreats 13. Long-term projects 14. Profitable company, no VC pressure 15. Part of the Devin Band ecosystem #### Tools we work with We're not religious about technology — we pick what fits the problem. That said, here's what we use most. If you know some of these and are curious about the rest, you'll fit right in. - React - Next.js - React Native - TypeScript - Laravel - Node.js - Python - PostgreSQL - AWS - DigitalOcean - Docker - CI/CD - Claude - OpenAI - n8n - Flowise - Custom AI tooling - Figma - Linear - Notion - Slack #### The people you'd work with No org chart needed at 20 people. You'll know everyone by name within a week. Here are a few of them. > {% smallText %}— That's 6 out of 20. The rest you'll meet when you join.{% /smallText %} ### How hiring works **Q: Do you hire remotely?** Yes — most of the team works remotely or hybrid. We have an office in Bratislava if you prefer working from there, but it's not required. We do meet in person a few times a year. **Q: Do I need to speak Slovak?** Not necessarily. Our internal communication is a mix of Slovak and English. If you're working with international clients, English is what matters. But some understanding of Slovak helps in day-to-day team life. **Q: What's the team structure like?** Flat. There are no layers of middle management. Project teams are small — typically a PM, designer, architect, and a few developers. Everyone talks to everyone. **Q: Do you work with AI daily?** Yes. We use AI tools across code, research, testing, and documentation. It's not a gimmick — it's part of how we work. You'll be expected to use AI where it helps, and know when it doesn't. **Q: Can I contribute to internal products?** Absolutely. Kontentino and Allfred both started as internal projects. We actively encourage people to build tools and products alongside client work. Some of those become real businesses. --- ## Get in touch URL: https://meetbrackets.com/contact > We'd love to hear from you at [connect@meetbrackets.com](mailto:connect@meetbrackets.com) or [+421 910 120 009](tel:+421910120009). #### Coffee's on us Our cowork space is open for thinking together. If you'd like to join us for a coffee and a good conversation, we're at [Innovators Hub](https://www.innovatorshub.sk/) in Bratislava. ##### Office Slávičie údolie 47, Bratislava, Slovakia **BRACKETS by TRIAD s.r.o.** Brigádnická 27, 841 10 Bratislava, Slovakia Reg. no: 48065633 VAT ID: SK2120059128 --- ## Cookie Policy URL: https://meetbrackets.com/cookie-policy ## What This Covers A cookie is a small file a website stores in your browser. This page explains exactly what meetbrackets.com stores, why, and what happens only if you agree. Most of this website runs without any cookies at all. Marketing cookies exist on a small number of campaign pages, and only after you accept them. ## Cookies We Set Without Consent These are strictly necessary for the website to work, so they do not require consent. - **`brackets_consent`** — stores your cookie choice, its version, and when you made it, so we do not ask again on every page. First-party, expires after 12 months. - **`skipHeaderEntrance`** — a session entry (not a cookie in the tracking sense) that skips the header intro animation when you navigate between pages. It is deleted when you close the tab. Neither is used to track you, to build a profile, or to share anything with third parties. ## Cookies We Set Only With Your Consent **Marketing (Google).** On our campaign landing pages and on the Free Code Audit page, we ask whether we may measure which advert or campaign brought you here. Without that, we cannot tell which spend leads to real enquiries. - Set by Google, loaded through Google Tag Manager and Google Analytics 4. - Nothing from Google is loaded at all until you accept. If you reject, no request is made to Google and no Google cookie is created. - Names and lifetimes are defined by Google. The most common are `_ga`, `_ga_*` and `_gcl_au`, with lifetimes of up to 24 months. - We use Google Consent Mode, which means Google is told your choice before any tag runs. We do not use these cookies on articles, case studies, or the rest of the website. ## Analytics Without Cookies We use Plausible Analytics to see how many people read a page. Plausible sets no cookies and collects no personal data: all figures are aggregated and anonymous, so no consent is required for it under GDPR. ## Changing or Withdrawing Your Choice Use the **Cookie preferences** link in the footer of any page. You can switch marketing cookies off again there at any time, just as easily as you turned them on. When you withdraw consent, we tell Google to stop and remove the Google cookies we can reach. A script already loaded on the page you are looking at cannot be unloaded, but it stops collecting; from your next page view onwards nothing from Google is loaded at all. If we materially change the categories or this wording, we raise the version of our consent record and ask you again. You can also block or delete cookies in your browser settings. The website keeps working either way — nothing here is behind a cookie wall. ## Related Our [privacy policy](/privacy-policy) covers the rest: what personal data we process, on what legal basis, and your rights under GDPR. ## Contact Questions about cookies or anything else on this page: connect@meetbrackets.com. --- ## What is your legacy code really costing you? URL: https://meetbrackets.com/legacy-codebase > An honest read of the system you depend on. ### What it actually costs you #### A change that used to take a week now takes a month. Nobody remembers when that happened, and nobody has costed it. That is how legacy actually works. A legacy codebase audit is where the costing starts. It maps what you actually have: the architecture, the code quality, the real risks. Then it tells you what to move, what to keep, and in what order. The goal isn't a rewrite for its own sake. The goal is knowing what's solid, what's fragile, and in what order it all moves, now that [moving off legacy code costs less than it used to](/thinking/legacy-code-migration-cost). ### What you get - **Full Assessment** — Architecture, code quality, test coverage and [technical debt](/legacy-codebase/technical-debt), mapped and rated so you can see the whole picture at once. - **Codebase Deep-Dive** — We read the code that matters most, document how it actually works, and flag the parts that will hurt you as you grow. - **Risk & Security Review** — Dependency, security and reliability risks surfaced and prioritised, so the urgent gets separated from the merely annoying. - **A Migration Plan** — The route off the system you have: what moves first, what gets rebuilt, what gets retired, and what can safely stay. Effort and impact for each step. ### How the audit works ### Who reads your code #### One senior architect reads your code. Not a tool, not a junior. However you hand over the code, Samuel is the account you grant read access to. He reads the code himself, and he stands behind the plan. ### Common questions **Q: How long does a codebase audit take?** Most audits run two to four weeks, depending on the size of the system and how much context is available. **Q: Do you need our whole team's time?** No. We need read access to the code, a short kickoff, and a few conversations with people who know the system. The heavy lifting is ours. **Q: Will you recommend a rewrite?** Only if the evidence points there. Most systems don't need a full rewrite; they need targeted fixes and a clear plan. We tell you either way. **Q: What do we get at the end?** A written assessment, a risk register, and a migration plan with effort and impact for each step. Everything in plain language. **Q: Can you also do the work you recommend?** Yes. Many audits lead into a focused engagement, but there's no obligation. The plan stands on its own. --- ## Talk to us right from your Claude URL: https://meetbrackets.com/mcp > We built an MCP server so you can share your idea, book a meeting, or just say *Hello* 👋 – directly from your Claude. No login required. ## **What you can do** - **Send a message** — say hello, ask a question, pitch a project - **Book a meeting** — 15-minute intro or 30-minute briefing, calendar invite sent automatically - **Check availability** — see open meeting slots before booking ## How to add it 1. Open [Customization → Connectors](https://claude.ai/customize/connectors) in Claude 1. Click **Add custom connector** 1. Paste the server URL `https://mcp.meetbrackets.com/mcp/brackets` 1. Click **Add** ![](chrome_II0bo6djIE.png)![](chrome_R1h9mD9pRG.png) ## Try it Once connected, ask Claude to do any of these: > – "Send a message to BRACKETS, looking for a partner to build the mobile app we've just discussed" > – "Ask BRACKETS if they do AI assistants for both web and mobile platforms" > – "Book a meeting with BRACKETS next Thursday" --- ## Replace your SaaS subscription with software you own URL: https://meetbrackets.com/saas-replacement > When a tool no longer fits how you work, owning the software is often cheaper than staying. ### What it is #### SaaS replacement is the honest case for building software you own instead of renting a tool that no longer fits how your team works. The monthly fee is rarely the real cost. What you actually pay is in the workarounds, the lock-in, and the flexibility you lose as you grow. BRACKETS puts a number on that, then helps you decide what's worth building and [owning](/own). ### Why teams outgrow SaaS ##### The tool stops fitting the work. Off-the-shelf SaaS is built for the average customer, not for how your team actually operates. As you grow, the gaps show up as manual workarounds, exports and re-imports, and a stack of integrations holding the whole thing together. The subscription is the visible cost. The workarounds are the real one. ### What owning gets you - **An Honest Cost Picture** — We price the full cost of staying versus building: subscriptions, workarounds, and the time your team loses to a tool that no longer fits. - **Software That Fits** — Instead of bending your process to the tool, you get software shaped around how your team actually works. - **Software You Own** — No per-seat pricing that scales against you, no roadmap you don't control. You own the code and the direction it takes. - **A Way Off Lock-In** — We map your data, integrations and workflows so the switch is planned and safe, not a leap of faith. ### How we help you decide ### Common questions **Q: Isn't building always more expensive than a subscription?** Not always, and less often than it used to be. Building got substantially cheaper as AI took over the repetitive part of the work, so the comparison that held five years ago no longer does. A subscription still looks cheap until you add the workarounds, the integrations, and the time lost to a tool that doesn't fit. We price both sides properly and tell you when staying is the better call. **Q: Do we have to replace everything at once?** No. Most teams replace one tool where the pain is clearest, prove the value, then decide what's next. We help you pick the right first step rather than a big-bang rewrite. **Q: What happens to our data in the current tool?** We map your data and integrations up front, so a switch is planned around exporting and migrating what matters. Getting your data out cleanly is part of the plan, not an afterthought. **Q: Will you tell us if we shouldn't replace a tool?** Yes. If a SaaS tool still fits and the numbers favour staying, we'll say so. The goal is the right decision, not a project. --- ## Terms and Conditions URL: https://meetbrackets.com/terms-and-conditions Terms version: 2026-08.3, effective August 6, 2026 These terms cover the BRACKETS Free Code Audit, a service offered through the tools on this website. By submitting an audit request you agree to the terms below. ## What the Free Audit is The Free Audit is a no-cost review of a codebase you own or are authorized to share. You give us read-only access to a repository, or upload an archive of the code, and our team reviews it and returns a written summary along with an offer to discuss the findings on a call. The audit is provided free of charge and creates no obligation for you to engage BRACKETS for further work. ## What it is not The Free Audit is not a legally binding non-disclosure agreement. If your situation requires a signed NDA before you share code, contact us at connect@meetbrackets.com and we will arrange one. Submitting an audit request is also not a commitment to a paid engagement by either side. ## Confidentiality and AI Your code is treated as confidential. Access is limited to the BRACKETS team members carrying out the audit and to the AI coding assistants they use while doing so. Those assistants are Anthropic services, used under business plans on which your code is not used to train any model. ## Repository access and revocation When you grant repository access, it should be read-only, and you can revoke it at any time. We recommend revoking access once the audit is complete. If you cannot grant access directly, you can upload an archive of the code instead. ## Uploaded archives and retention Uploaded archives are stored at rest in private object storage in the European Union (Paris region). An archive is deleted on request, and in any case no later than 30 days after the audit is completed. ## Personal data The personal data you provide (such as your name and email) is handled as described in our [Privacy Policy](/privacy-policy). ## Intellectual property Your code and any intellectual property in it remain yours. The audit summary we produce is provided for your use. ## Liability The audit is provided as-is and for informational purposes. BRACKETS is not liable for decisions made on the basis of the audit summary. ## Contact Questions about these terms can be sent to connect@meetbrackets.com. --- # Case studies ## Digitalization and Optimization of Core Sales Process URL: https://meetbrackets.com/case-studies/digitalization-and-optimization-of-core-sales-process Client: IKEA Categories: crm, web-portals ### Overview #### Digitalization and optimization of the entire sales workflow across departments, suppliers, and customers. One solution now covers the process from the first appointment to final deal details. ### The Situation ##### IKEA staff relied on Excel, emails, and calendars to manage the entire sales process. Communication across departments, suppliers, and customers was fragmented across multiple channels with no unified system. This was causing miscommunication issues and a lack of effectiveness in day-to-day operations. With stores across multiple countries, the complexity only grew — different processes, different tools, and no visibility into the overall sales workflow from first appointment to final deal. ### The Real Problem ##### Then COVID-19 changed the rules overnight. Customers could no longer browse stores freely. IKEA needed to rapidly enable remote appointment scheduling and online order management — while keeping in-store sales running. The challenge wasn't just going digital. It was doing it across 8 stores in 3 countries, supporting 4 languages, and integrating with IKEA's existing infrastructure — all under extreme time pressure. ### Key Decisions - **One Platform for Everything** — Instead of patching existing tools, build a single unified solution covering the entire sales process from first appointment to final deal. - **Multi-Country from Day One** — Design for 3 countries and 4 languages from the start, not as an afterthought. One codebase, local flexibility. - **Zero IT Skills Required** — Staff adoption was critical. The interface had to be intuitive enough for any store employee — no training, no technical knowledge needed. - **Deep IKEA Integration** — Plug into IKEA's existing infrastructure rather than replacing it. All departments modified to handle online orders with click & delivery. ### The Outcome ##### IKEA maintained its sales performance — with zero layoffs. The solution enabled customers to schedule sessions at stores or remotely. All departments were connected through a single workflow. Despite the disruption, IKEA maintained approximately 50% of in-store sales compared to the previous year, with no staff layoffs. - **~50%** — In-store sales retained - **8** — Stores deployed - **3** — Countries - **0** — Layoffs - **4** — Languages supported ### Related --- ## Dr. Max Leaflet Management System URL: https://meetbrackets.com/case-studies/dr-max-leaflet-management-system Client: Dr.Max Categories: web-portals, healthcare ### Overview #### We replaced a fragmented, manual leaflet process with a purpose-built system — and used AI to put a working version in Dr. Max's hands within days. ### The Situation ##### Every leaflet started in a spreadsheet. Dr. Max, a leading European pharmaceutical retail group operating across Central and Eastern Europe, built its promotional leaflets almost entirely by hand. Product data lived in exported Excel files, items were added one by one, and historical information had to be tracked down manually each time. Products were individually cut out of finished PDFs, and every leaflet meant slow, fragmented back-and-forth between Dr. Max, its creative agency, and dozens of suppliers. It worked but it consumed time, capacity, and attention at every step. ### The Real Problem ##### Manual work that was both costly and easy to get wrong. The process didn't just take time — it left constant room for inconsistencies, and the coordination overhead grew with every supplier and every edition. Time, capacity, and attention were being spent on repetitive work instead of the leaflets themselves. Dr. Max needed one reliable system: a single source of truth for product data, a faster production cycle, and a workflow designed to cut manual effort by more than half. ### Our Approach 1. **Discovery & brief.** We opened with a single call to define Dr. Max's real workflow and lock the brief — so everything we built mapped to how the team actually works. 2. **AI-accelerated MVP.** Using AI, we stood up a functional MVP in just a few days — a working system in the client's hands fast, not weeks of slideware. 3. **Iterative refinement.** We tuned features and resolved edge cases based on real feedback gathered during hands-on testing, shaping the system around live use. ### What We Built - **Import & Merge Engine** — Excel import with built-in validation and intelligent conflict resolution, so product data lands clean every time. - **Centralized Product Library** — One source of truth holding images, prices, EAN codes, claims, seasonality, and full usage history for every product. - **Visual Leaflet Editor** — An interactive grid with color-coded data-quality indicators that show at a glance what's complete and what's missing. - **Automation Engine** — One-click supplier messages for missing data, plus automatic slicing of final PDFs into individual product images by grid. ### The Outcome ##### Delivered, deployed, and already in production. The system is live. Dr. Max has already used it to prepare its first real leaflet. By automating the most repetitive steps and consolidating product data into a single source of truth, it's built to cut manual effort by more than 50% while speeding up both supplier communication and the overall production cycle. ### Testimonial - **Days** — From brief to working MVP - **10/10** — Client satisfaction rating - **50%+** — Manual work targeted for reduction ### Related --- ## Smarter Investing Experience and AI Assistant URL: https://meetbrackets.com/case-studies/smarter-investing-experience-and-ai-assistant Client: Crowdberry Categories: fintech ### Overview #### A regulated investment platform giving over 16,000 investors direct access to vetted companies and real estate across Slovakia and the Czech Republic. ### The Situation ##### A live, regulated platform with a decade of trust — ready to be pushed further. Crowdberry has operated for over ten years in Slovakia and the Czech Republic under the supervision of the national banks, giving people direct access to investment opportunities in vetted companies and real estate — either as co-owners through equity stakes or as lenders through loans. With more than 16,000 registered investors already on the platform, Crowdberry wanted to take the experience further: making investing accessible even to less technically experienced users, while keeping the security and trust expected of a regulated financial service. ### The Real Problem ##### Two areas were holding the platform back from its full potential. The secondary market — where investors could act on opportunities they had missed — was hard to find and offered only basic functionality. It saw little use, and many investors were not even aware it existed. At the same time, the investor dashboard surfaced only a basic list of investments, without the detailed data investors needed to make informed decisions about their portfolio. ### Key Decisions - **Rework the Investment Journey** — Expand the available investment options and redesign the flow end-to-end, so investing feels intuitive even for less technical users. - **Surface the Data That Matters** — Enrich the investor dashboard with the detailed portfolio data that was previously missing — giving investors a clearer view to act on. - **Bring the Secondary Market Forward** — Improve visibility and functionality of the secondary market so investors can act on opportunities they had previously missed. - **Self-Updating AI Assistant** — Add a conversational assistant whose knowledge stays current as the platform's content changes, with a foundation ready to extend into mobile. ### The Outcome ##### A faster, clearer platform — with information always within reach. The reworked investment flow and enriched dashboard gave investors a more intuitive experience and clearer visibility into their portfolio. The AI assistant made information easier to reach and reduced manual upkeep by keeping its knowledge current on its own. With a continued focus on quality and reliability, the result is a more stable, easier-to-maintain platform — important qualities for a regulated service trusted by thousands of investors. ### Related --- ## Mobile Platform for Financial Services Across Six Countries URL: https://meetbrackets.com/case-studies/iwinners-client-application Client: Winners Group Categories: fintech, mobile-app ### Overview #### End-to-end mobile platform empowering customers across six countries to take confident control of their personal finances — insurance, mortgages, investments, and more. ### The Situation ##### A financial services leader serving customers across Central and Southeastern Europe. Winners Group has spent over 16 years building a network of business partners and specialized advisors across Slovakia, Bulgaria, Ukraine, North Macedonia, Poland, and Romania. Through this network, they provide end customers with insurance, mortgages, leasing, real estate, savings and investment services, and risk management. They already had a mobile application, but it wasn't delivering the value their customers needed. The client approached us with a clear goal: take the existing app to the next level — giving users a clearer overview of their financial products and helping them manage their personal finances more effectively. ### The Challenge ##### One application, six countries, zero fragmentation. The application had to serve users across multiple markets, each with different regulatory environments, product specifics, and local requirements. Building separate apps per country would have been unsustainable — leading to duplicated effort, inconsistent experiences, and a maintenance burden that grows with every new market. The real challenge was designing a single, unified application capable of handling country-specific behaviors without fragmenting the user experience. Flexibility at the market level, consistency at the product level. ### Key Decisions - **Full-Stack Delivery** — Own the entire product — iOS and Android applications, backend services, and a backoffice system supporting the client's internal operations. No handoffs, no gaps. - **Core System Integration** — Connect directly to InsuranceContractManager — the client's brokerage system and single source of truth for contracts and product data. No data duplication, always up to date. - **Multi-Country Architecture** — Design for six markets from the start. One codebase, one product experience — with the flexibility to accommodate country-specific regulatory and product requirements. - **UX-First Design** — Craft a user experience focused on clarity and confidence — helping customers quickly understand their financial portfolio and take action on their products. ### The Outcome ##### A modern platform that turns a mobile app into a strategic asset. The new iWinners application gives Winners Group a scalable foundation for engaging with their end customers across all markets. The multi-country architecture makes future expansion significantly easier — new markets can be onboarded within the same application without rebuilding. Customers now have a clearer, more intuitive way to view and manage their financial products, supporting better financial decision-making. And for Winners Group, the app has become a direct communication channel — enabling them to engage with their users more frequently and more meaningfully than ever before. - **6** — Countries supported - **2** — Platforms (iOS & Android) - **1** — Unified application ### Related --- ## How we combined digital innovation with better health services URL: https://meetbrackets.com/case-studies/how-we-combined-digital-innovation-with-better-health-services Client: Mavie Next Categories: healthcare, e-commerce ### Overview #### Modern and accessible health services for individuals and companies in German-speaking countries — from at-home blood testing to telemedicine and corporate wellness. ### The Situation ##### Mavie Next operates an interconnected ecosystem of digital health services. The platform combines at-home blood testing, telemedicine, personalized health recommendations, and corporate healthcare solutions — all serving individuals and companies across German-speaking countries. The platform combines at-home blood testing, telemedicine, personalized health recommendations, and corporate healthcare solutions — all serving individuals and companies across German-speaking countries. BRACKETS joined as an external development partner, contributing technical expertise while supporting Mavie's competent, agile in-house team. The partnership was built on trust, clear communication, and shared objectives. ### The Real Problem ##### Four products, dozens of integrations, and constantly shifting requirements. Each of Mavie's products — MavieMe, MaviePortal, Mavie Telemed, and MavieWork — required complex integration of multiple internal and external services. The system needed to be flexible enough for rapid feature adaptation while maintaining stability. On top of that, initially unclear task descriptions and evolving product requirements demanded a process improvement — clearer documentation, streamlined project management, and tighter feedback loops between teams. ### What We Built - **MavieMe** — Convenient home blood testing without doctor visits. Users receive lab results with professional commentary and personalized health recommendations. Custom dashboards for operations and doctors. - **MaviePortal** — A unified entry point where users access all Mavie services. Includes a recommendation engine based on mood, health, and interaction history, plus enhanced navigation and localization. - **Mavie Telemed** — Simplified access to healthcare professionals through digital consultations. A robust booking and scheduling system with embedded video calls via Zoom integration. - **MavieWork** — Corporate health benefits platform supporting companies with holistic employee wellness — onboarding, program management, and consultations. ### The Outcome ##### Four interconnected health platforms, delivered and continuously improved. Across the four products, we built custom content editor dashboards, doctor result commentary tools, automatic product synchronization with Stripe and Google Merchant Center, a recommendation engine, a booking system with Zoom integration, and corporate health management features. Process improvements led to clearer documentation and more efficient collaboration between teams. ### Tech Stack ##### The technologies powering Mavie's health ecosystem. - Next.js - Turborepo - Hasura - GraphQL - TypeScript - Contentful - Zod - Stripe - Zoom API - GCP - Sentry - Airtable ### Testimonial ### Related --- ## Next-Gen LMS for Nuclear Medicine Education URL: https://meetbrackets.com/case-studies/next-gen-lms-for-nuclear-medicine-education Client: EANM Categories: web-portals, healthcare ### Overview #### A purpose-built learning management system replacing a generic platform — designed specifically for the unique demands of nuclear medicine education. ### The Situation ##### EANM relied on a generic LMS that wasn't built for nuclear medicine education. The European Association of Nuclear Medicine, established in 1985, is Europe's leading organisation advancing nuclear medicine. With an Annual Congress attracting over 8,700 medical experts globally, EANM needed a robust educational platform to support its growing programs. But the existing system was a generic off-the-shelf LMS — packed with superfluous features while missing critical functionalities specific to nuclear medicine. Users were forced into excessive workarounds, customization was severely limited, and operational costs kept climbing. ### The Real Problem ##### The platform was actively hindering the learning experience it was supposed to enable. Generic functionality meant that educators couldn't structure courses the way nuclear medicine demands. Students navigated through irrelevant features to find what they needed. Administrators spent more time fighting the system than managing programs. The gap between what the LMS offered and what EANM actually needed was growing wider — reducing program effectiveness and driving up costs. A complete rethink was the only path forward. ### Key Decisions - **Simplify, Don't Accumulate** — Strip away unnecessary features from the original system instead of adding more. Create a streamlined experience focused purely on nuclear medicine education needs. - **Built-In Customization** — Design the system with extensive modification capabilities that administrators can use without requiring developer intervention — giving EANM full control over their platform. - **Complete UX Overhaul** — Redesign the entire interface from scratch, prioritizing intuitive navigation and responsive design to create an engaging learning environment. ### The Outcome ##### A tailored platform that precisely matches nuclear medicine education requirements. The new LMS eliminated the friction of the previous system. Administrators spend significantly less time on management, operational costs dropped substantially compared to the generic solution, and the learning experience became more intuitive and engaging. The future-ready architecture now supports ongoing evolution, with a planned mobile application on the roadmap. - **8,700+** — Medical experts at Annual Congress - **1985** — Association established - **1 LMS** — Purpose-built for nuclear medicine ### Testimonial ### Related --- ## Unified Healthcare Ecosystem for Mothers & Babies URL: https://meetbrackets.com/case-studies/unified-healthcare-ecosystem-for-mothers-babies Client: Danone Categories: healthcare, mobile-app, web-portals ### Overview #### A multi-channel advisory ecosystem providing personalized healthcare guidance for mothers and expecting mothers throughout their parenting journey. ### The Situation ##### Growing Demand for Digital Parental Support Danone is a global leader with a unique health-focused portfolio in food and beverages. The Nutricia brand delivers an important part of Danone's mission — specialized nutrition for mothers and babies. Nutricia wanted to develop brand awareness among mothers and become a thought leader in the industry for children's nutrition and supplements. With a growing demand from customers for online experience and education, the traditional advisory channels were no longer sufficient to meet the expectations of modern parents seeking trusted, accessible healthcare guidance. ### The Real Problem ##### Disconnected Channels, Inconsistent Experience Despite having multiple touchpoints — web portal, mobile app, newsletters, live counseling — the experience was fragmented. Parents couldn't seamlessly transition between channels, and personalization was limited to basic segmentation rather than actual stages of child development. The data sat in silos without interoperability potential. Nutricia needed a unified, GDPR-compliant data infrastructure that would enable personalized experiences at scale while consolidating multiple data sources into a single warehouse — opening the door for future integrations and innovation. ### Key Decisions - **Modular Ecosystem Architecture** — Build interconnected modules — portal, CRM, mobile app, Exponea, push notifications — sharing a unified data warehouse instead of a monolithic platform. - **GDPR-First Data Strategy** — Design the entire data infrastructure around privacy compliance from day one, consolidating multiple data sources into a single compliant warehouse. - **Specialist-Powered Technology** — Integrate live chat and professional counseling directly into the digital experience, blending human expertise with automated engagement tools. - **Long-Term Partnership Model** — Commit to continuous evolution through ongoing SLA support rather than one-time delivery, enabling iterative improvements since 2010. ### The Outcome ##### A Trusted Ecosystem Serving Generations Nutriklub has become the go-to resource for hundreds of thousands of parents. The unified ecosystem — spanning web portal, mobile app, CRM, newsletters, push notifications, and marketing automation — delivers personalized content based on each child's stage of development. Engagement tools like baby diaries, development charts, and allergy risk calculators keep parents coming back. The modular architecture enabled rapid feature expansion while maintaining performance and compliance. A decade-long partnership has proven the value of continuous evolution over static delivery. - **10 years** — of continuous partnership - **400K+** — parents in the ecosystem - **25K+** — questions answered live ### Related --- ## Patient Booking Platform for a Mental Health Clinic URL: https://meetbrackets.com/case-studies/calma Client: Calma Categories: healthcare ### Overview #### Together with the Calma team, we built a patient Client Zone and booking engine for a mental health clinic, one place where patients book their own appointments, follow their treatment, and pay online. ### The Situation ##### Calma is a mental health clinic caring for children, adolescents and adults in Bratislava. The clinic provides diagnostics and therapy for conditions such as ADHD, autism, anxiety and depression. These aren't one-off visits. Each patient goes through a structured program in which individual sessions and specialists follow one another in a specific order. When they came to us, most things were handled manually: appointments booked by reception over the phone, no self-service for patients, and no clear digital record of where a patient was within their program. ### The Real Problem ##### It looks like simple booking. In reality, it's many rules that all have to hold at once. The brief sounded clear: a Client Zone where patients book, reschedule and cancel appointments themselves, see their packages and documents, and pay online. On top of that, a clean interface for clinic staff and a connection to the systems the clinic is legally required to use. The catch was in the details. Every available slot has to satisfy dozens of conditions at the same time: different rules for children and adults, the correct sequence of sessions, the availability of a specific specialist and room, enough credit on the patient's account, and whether the patient is even allowed to book on their own. No off-the-shelf tool on the market handles that combination the way the clinic needed. Neither did our first version, which is exactly why we changed our approach. ### What We Built ##### From a ready-made plugin to a tailored platform, in three chapters. We started where most projects start: looking for the fastest path to a working solution. We evaluated several ready-made booking tools and built a prototype. It turned out they weren't flexible enough for the clinic's needs, since they couldn't handle session sequencing, credit logic, or bulk rescheduling. So we went hybrid. We paired a ready-made foundation for the calendar and booking with parts we built from scratch: the Client Zone, the staff dashboard, and the layer that ties all the data together. That meant we didn't have to build everything from zero, while keeping full control over the rules that matter most to the clinic. Along the way we also replaced two third-party subscription tools the clinic had been paying for. Instead of a third-party form/data-collection SaaS, we built the clinic's own questionnaires directly into the platform. And instead of a separate CRM tool, we built in activity tracking and a communicator. Bringing these in-house meant fewer disconnected tools, lower running costs, and patient data living in one place rather than scattered across external services. The hardest part was connecting to the medical records the clinic is required to keep. That system communicates in an unusual way and offers none of the standard connections we're used to. We built the integration so that booking happens immediately and records sync in the background. - **Client Zone** — A clear home for the patient: book appointments, view session history and documents, and pay online. Under a single login, a parent can also manage their children's appointments. - **Smart booking** — For every available slot, the system weighs dozens of rules in the background, so the patient is only offered times that actually make sense and are genuinely available. - **Built-in questionnaires & communication** — We replaced separate subscription tools with the clinic's own questionnaires plus a built-in communicator and activity tracking, so intake forms and patient contact live inside the platform, not in external services. - **Staff & reception dashboard** — Complete patient management in one place: calendars, contacts, the care journey, and the option to arrange an appointment manually when the situation calls for it. ### Key Decisions - **Start by buying, but know when to stop** — We first evaluated several ready-made tools and built a prototype, and only then decided to go custom on the core. The right call isn't always "build from scratch." It's knowing the point at which customizing a ready-made tool outweighs what you bought. - **Understanding how the clinic works beats a task plan** — A couple of hours each week spent talking through how the clinic actually runs told us more than any brief. The dozens of booking rules didn't come from a document. They came from watching how reception really schedules patients. - **The patient never waits on background systems** — For a new patient, the medical records require manual approval first. We designed it so the booking goes through immediately and the sync catches up in the background, so the patient never notices the wait. - **Replace subscription tools instead of stacking them** — Rather than wiring up more third-party services, we built questionnaires, communication and activity tracking directly into the platform, replacing a data-collection SaaS and a CRM subscription. Modern AI-assisted development made it realistic to bring this in-house within a sensible timeline, cutting recurring costs and keeping patient data in one place. ### The Outcome ##### Calma now runs patient self-service, specialist scheduling, and mandatory records on a single platform. Patients book their next session, check upcoming appointments, and pay online, without calling reception. Clinic staff manage the entire patient journey from a single overview, the medical records stay current, and specialists have accurate calendars. The platform replaced a fragmented manual process and set the stage for the next phase: an assistant for Slovak-language patient communication, automatic pre-filling of intake questionnaires, and advanced insights into specialist workload. - **20+** — Rules weighed for every slot - **3,000** — Patient records migrated - **100%** — Bookings self-service ### Testimonial ### Tech Stack - Laravel 12 - Vue 3 - Shadcn - Curo API - Google Calendar API - Metabase - MySQL - SMS Gateway - GDPR ### Related --- ## Digitalization and Optimization of International Team Workflow URL: https://meetbrackets.com/case-studies/ikea-production-tool Client: IKEA Categories: crm ### Overview #### Together with the IKEA team we created a tool to digitalize and streamline team workflow across 3 countries. ### The Challenge ##### IKEA manages 8 department stores across 3 countries — efficient communication between departments is critical. Teams relied on email to coordinate internal tasks, requests, and cross-department workflows. With no centralized system, important requests got buried in overflowing inboxes, follow-ups were missed, and there was no visibility into task status or team workload. The lack of structure meant that every store operated slightly differently, making it nearly impossible to standardize processes or measure performance across the organization. ### The Solution ##### A workflow management system & service desk that replaced email with an intuitive task hub. The tool was designed to save time, resources, and full mailboxes by providing a single platform where all tasks are tracked, assigned, and resolved. Instead of scattered email threads, teams now have full evidence of all tasks with clear ownership and deadlines. Custom workflows, roles, and permissions ensure that each team member sees exactly what they need — nothing more, nothing less. Management gets real-time reports and dashboards for data-driven decision making. ### Key Decisions - **Intuitive Interface** — Design created specifically to shorten the adoption process to a minimum — no training required for store employees to start using the tool immediately. - **Role-Based Access** — Different role types with distinct front-end and back-end experiences, ensuring each user sees only what's relevant to their responsibilities. - **Management Reports** — Built-in statistics and evaluation through streamlined reporting, giving leadership full visibility into team performance and bottlenecks. - **Unified Dashboard** — A central hub to manage internal cooperation across all departments and countries, replacing fragmented email communication. ### The Outcome ##### IKEA now manages internal cooperation across 3 countries from a single platform. The workflow management tool transformed how teams communicate and collaborate. Tasks that previously got lost in email are now tracked with full transparency. The intuitive design ensured rapid adoption across all stores, while management reports provide actionable insights for continuous improvement. - **8** — Department stores connected - **3** — Countries on one platform - **1** — Unified workflow system ### Related --- ## Online investment platform for retail customers URL: https://meetbrackets.com/case-studies/online-investment-platform-for-moon Client: Moon Categories: fintech ### Overview #### An online investment platform that gives retail customers real-time access to their funds and portfolio. ### The Challenge ##### Everything ran through in-person meetings. The provider of financial services had to sign new contracts with customers in person, and customers had no real-time access to their funds. ### The Solution ##### A digital onboarding flow and a private customer zone. We digitalized the onboarding process and contract creation, and built a private online customer zone with a full portfolio overview, backed by a complex integration with the provider of financial services. ### Highlights ### Related --- ## Custom-Built CRM for Complex Financial Sales URL: https://meetbrackets.com/case-studies/tailor-made-crm-for-global-finance Client: Global Finance Categories: fintech ### Overview #### A tailor-made CRM that runs the entire sales workflow for a financial services provider, from lead generation to customer care. ### The Challenge ##### The team needed to digitalize and speed up its core processes. Global Finance wanted to digitalize and accelerate its lead generation and customer care, and run them through one system instead of scattered, manual steps. ### The Solution ##### A tailor-made CRM covering the whole workflow. We built a CRM that manages the entire process: collecting leads from various sources, financial analysis of the client, portfolio proposal, and automatic management of the client's products. It includes a complex mortgage calculator with detailed information from all Slovak banks. ### Highlights ### Related --- ## Boosting sales efficiency with a custom opportunity management system URL: https://meetbrackets.com/case-studies/boosting-sales-efficiency-alef-nula-opportunity-management Client: Alef Categories: crm ### Overview #### A custom Opportunity Management System built for ALEF NULA — a leading CEE IT solutions provider — fully integrated with their Microsoft stack and rolled out across nine European countries. ### The Challenge ##### Off-the-shelf tools couldn't keep up — and an internal build fell short. ALEF NULA, a prominent IT solutions provider in CEE, came to us after exhausting other options. No existing market solution could accommodate the specific workflow and business model behind their sales operations, and an earlier internal attempt — built on Microsoft Power Apps — did not meet expectations in terms of usability and functionality. On top of that, the team required a highly keyboard-optimized interface for rapid data entry. None of the available systems delivered an efficient enough user experience, so ALEF NULA needed a bespoke solution that could integrate seamlessly with their existing Microsoft technology stack. ### Our Approach ##### From deep requirements analysis to a tailored, end-to-end system. We began with an in-depth analysis of ALEF NULA's requirements to craft a tailored specification, then translated it into wireframes and — after client feedback — into detailed graphical designs. From there we developed the web-based Opportunity Management System from scratch, customising every flow to fit the way the team actually works. The system was designed to operate across nine European countries and was engineered to handle large volumes of data with quick load times — including real-time financial calculations across seven different currencies without performance lags. ### What We Delivered - **Custom Web System** — A fully bespoke web-based Opportunity Management System built from scratch around ALEF NULA's workflow, rolled out across nine European countries. - **Microsoft Stack Integration** — Seamless integration with Microsoft Entra ID for authentication and Microsoft Dynamics Navision for data consistency and security. - **Keyboard-Optimized UX** — Keyboard-only data entry across the entire interface, dramatically speeding up the sales process and reducing the fatigue typically associated with mouse-driven workflows. - **Real-time Multi-currency Calculations** — Live financial calculations across seven currencies, with custom summary statistics built into the UI and no performance trade-offs under heavy data loads. ### The Outcome ##### A new standard for ALEF NULA's sales operations. The Opportunity Management System significantly improved productivity by streamlining the opportunity management process end-to-end. The tailored UI and UX — custom summary statistics paired with keyboard-optimized controls — enhanced the day-to-day experience for every user of the system. Real-time calculation of financial indicators across multiple currencies improved financial reporting and accuracy. Beyond the immediate gains, the project set a new standard inside ALEF NULA for how custom IT solutions can shape operational efficiency and user satisfaction. - **9** — European countries the system serves - **7** — Currencies with real-time financial calculations - **2** — Microsoft platforms integrated — Entra ID & Dynamics Navision ### Related --- ## Driving Growth in Logistics: Mobile App for BOX ID Systems URL: https://meetbrackets.com/case-studies/driving-growth-in-logistics-mobile-app-for-boxid Client: BoxID Categories: mobile-app ### Overview #### A custom mobile application built on top of BOX ID's existing backend — opening a new sales channel for courier companies and securing a key client whose fleet relied on non-standard hardware. ### The Situation ##### A leader in industrial logistics with a sophisticated backend. BOX ID Systems GmbH is a German company specialising in digital solutions for logistics and asset management. As a leader in industrial logistics and IoT in Central Europe and the Asia-Pacific region, BOX ID delivers powerful backend services that power some of the most demanding supply-chain operations on the market. Their offering was strong on the platform side — but reaching courier companies with that same power required a far simpler, field-ready experience than the existing tooling could provide. ### The Real Problem ##### A complex backend, a difficult last mile — and one client with the wrong hardware. The sophistication that made BOX ID's backend valuable also made it difficult to adopt. Couriers in the field needed a fast, dead-simple way to push requests into the system, but the existing solutions demanded a more complex approach than end-users could realistically handle on the move. On top of that, one key client operated a large fleet of non-standard hardware devices. Replacing that hardware was not an option — the cost would have been prohibitive. The solution had to meet the devices where they were, not the other way around. ### Key Decisions - **Product Discovery First** — Start with a thorough discovery phase — analysing the needs of BOX ID and their courier customers before committing to a technical direction. - **Frontend on Existing Backend** — Build a focused iOS and Android frontend that lets couriers submit requests directly into BOX ID's existing backend — no duplication, no platform rewrite. - **Custom Build for Non-Standard Hardware** — Ship a dedicated app variant tailored to the non-standard hardware used by a key client — protecting their existing fleet investment and securing the account. - **Store Launch & Client Training** — Take full ownership of Google Play and App Store releases, and train the client's team to manage and maintain the app long after launch. ### The Outcome ##### A new sales channel — and a key client kept on board. The mobile application opened a brand-new sales channel into the courier segment, letting BOX ID reach customers they previously struggled to serve. Outsourcing the mobile build lowered operational costs compared to staffing an in-house team, while the tailored hardware variant retained a major client whose fleet would otherwise have been impossible to support. In the field, couriers gained a simple, focused tool for using BOX ID's services — and BOX ID strengthened its position as an innovative provider of logistics solutions, with room to grow further into the courier services segment. - **2** — Platforms (iOS & Android) - **New** — Sales channel into the courier segment - **Retained** — Key client with non-standard hardware fleet ### Related --- ## Exceptional customer experience turned into e-commerce URL: https://meetbrackets.com/case-studies/exceptional-customer-experience-turned-into-e-commerce Client: ZITA Categories: e-commerce, web-portals, healthcare ### Overview #### A full-stack digital platform for a premium optical store — e-shop, booking system, customer profiles, and ERP integration, all in one. ### The Challenge ##### No digital presence for a premium retail experience. ZITA is a family-owned full-service optical store in the heart of downtown Bratislava. They offer comprehensive eye exams by experienced optometrists alongside a carefully curated selection of frames from small independent European manufacturers — handmade eyewear with exceptional quality and attention to detail. Despite their premium positioning, ZITA had no digital presence at all. They needed more than just a website — they wanted a complete online platform that would reflect the quality of their in-store experience: an e-shop for frames, a booking system for eye exams and frame fittings, and a customer zone where clients could manage their appointments and favourites. The client had a clear vision, high standards, and required close collaboration across multiple external parties. The complexity was significant from day one. ### The Solution ##### A platform built through deep discovery and tight cross-team collaboration. We started with an extensive product discovery phase — multiple workshops and meetings to fully understand what the client truly needed. ZITA was demanding in terms of detail and quality, which meant thorough planning before a single line of code was written. The project required tight collaboration across multiple parties simultaneously: a graphic studio handling visual design, a warehouse management vendor whose stock system we integrated with, and our own team covering frontend, backend, integrations, and CMS. ### What We Delivered - **2 Language Versions** — The entire platform — website, e-shop, booking system, and customer zone — is available in both Slovak and English. - **Booking System** — Calendar-based reservation system for eye exams and frame fittings, with automated customer notifications. - **Customer Profiles** — Personal accounts where customers can save favourite frames, view past purchases, and manage their bookings. - **Custom CMS** — A tailored content management system enabling staff to manage products, customers, and store operations. - **TISS Integration** — Real-time stock sync with TISS — the ERP system used by ophthalmologic clinics — for accurate inventory management. - **Product Discovery** — Extensive workshops to map requirements, align stakeholders, and define the full scope before development began. ### Collaborating Parties - Graphic studio - Warehouse vendor (TISS) - BRACKETS (frontend + backend + CMS) ### The Outcome ##### A digital home that matches the in-store experience. For the first time, ZITA had a digital home that matched the quality of their physical store — a polished, representative website where customers could browse and order frames, and book appointments for in-store visits. The booking system gave the team full visibility into customer flow, reducing administrative overhead and improving staff efficiency. The custom CMS became a daily operational tool for managing inventory, customer records, and store communications. Customer profiles added a layer of personalisation that strengthened loyalty — users can save favourite frames, track their orders, and manage reservations from a single account. Sales grew as a direct result of the new online channel. Today, we continue to support ZITA under an ongoing SLA agreement — covering everything from CMS updates and web maintenance to helping customers who can't log into their accounts. The relationship didn't end at launch; it evolved into a long-term partnership. - **3** — Core systems delivered — website + e-shop, booking, customer zone - **TISS** — ERP integration for real-time stock sync - **SLA** — Ongoing long-term support partnership ### In Production ### Related --- ## A joyful digital home for the little ones' eyes URL: https://meetbrackets.com/case-studies/joyful-digital-home-for-little-ones-eyes Client: Eyekido Categories: healthcare, web-portals ### Overview #### A premium presentation website with a booking system for a children's eye care centre — built on the same backend foundation as its sister brand, ZITA. ### The Challenge ##### A child-friendly digital identity, connected to ZITA. Eyekido is a modern eye care centre and optical store dedicated entirely to children, located right next to ZITA in Bratislava. Under one roof, they bring together paediatric ophthalmologists, optometrists, orthoptists, and opticians — all focused on protecting children's vision from an early age. Services range from entry-level eye exams and extended diagnostics to eye exercises and a curated selection of children's frames. As a sister brand to ZITA, Eyekido needed its own distinct digital identity — a beautiful, child-friendly presentation website that would communicate warmth and professionalism, and allow parents to easily book appointments. At the same time, the two platforms needed to feel connected: parents who are already ZITA customers should be able to see their children's Eyekido appointments and registrations within the same profile. ### The Solution ##### A standalone site with a shared backend. We built Eyekido as a standalone presentation website with a fully integrated booking system — no e-shop, but with a strong focus on user experience and the unique nature of the audience: parents booking on behalf of their children. The visual design was delivered by an external graphic studio — khn office — with whom we collaborated closely to ensure the final result was both true to the brand and technically flawless to implement. The key technical achievement was the shared backend: Eyekido was built on the same platform as ZITA, allowing us to connect the two systems. Parents registered at ZITA can see their children's Eyekido profiles, upcoming appointments, and visit history — all from within their existing ZITA customer account. ### What We Delivered - **Presentation Website** — A beautifully designed, content-rich website presenting all Eyekido services — eye exams, diagnostics, eye exercises, and children's frames — in a warm and approachable tone. - **Booking System** — An appointment reservation system for eye exams and other services, with automated notifications for parents. - **Shared Backend with ZITA** — Eyekido runs on the same backend infrastructure as ZITA. Parent accounts are linked across both platforms — a seamless experience for families already using ZITA. - **Connected Customer Profiles** — Parents registered at ZITA can view their children's Eyekido registrations, bookings, and history directly from their ZITA profile — no separate login needed. - **Custom CMS** — A content management system allowing the Eyekido team to manage articles, services, team profiles, and appointments independently. - **Curated Frame Catalogue** — A filterable showcase of children's eyewear brands, browsable by age group, helping parents find the right frames for every stage. ### Collaborating Parties - khn office (visual design) - BRACKETS (frontend + backend + CMS + ZITA integration) ### The Outcome ##### A connected ecosystem for families. Eyekido launched with a digital presence that perfectly matches its brand personality — playful, trustworthy, and clearly built for families. Parents can easily find information about services and book appointments online, reducing friction for first-time visitors. The shared backend with ZITA is the standout technical achievement of this project. Rather than building two completely separate systems, we created a connected ecosystem where family members are recognised across both platforms. A parent browsing ZITA for new frames can also check their child's upcoming Eyekido appointment — all in one place. This integration laid the groundwork for a long-term digital ecosystem serving both adults and children within the same family, reinforcing loyalty to both brands simultaneously. - **1** — Shared backend platform with ZITA - **Online** — Appointments booked without a phone call - **Connected** — Parent profiles link ZITA & Eyekido accounts ### In Production ### Related --- ## Mobile App for Workspace Management Platform URL: https://meetbrackets.com/case-studies/desk-ly-mobile-app-for-workspace-management Client: Deskly Categories: mobile-app ### Overview #### Extending a web-based workspace management platform with a dedicated mobile application for iOS and Android — built to make workspace reservations feel effortless on the go. ### The Goal ##### Bring the full workspace management experience to mobile. As part of a digital transformation initiative, our client set out to expand their web-based workspace management platform with a native mobile application for iOS and Android. The goal was to provide a seamless and intuitive experience for workspace reservations — minimizing the need for desktop interactions and improving overall user engagement. ### Our Approach - **Discovery & Planning** — Collaborated with the client to define core functionalities and identify UX/UI improvements tailored for a mobile-first experience. - **UX/UI Design Optimization** — Kept consistency with the web platform while streamlining navigation and interaction patterns for an intuitive mobile experience. - **Agile Development** — Iterative development cycle with regular client demos, allowing rapid adjustments and continuous feature refinements along the way. - **Localization & Scalability** — Designed to support five language mutations from the start and built on a foundation ready for future feature expansions. ### The Outcome ##### A faster booking experience and a future-ready foundation. Rigorous QA across multiple devices and platforms ensured high performance and a smooth user experience at launch. The app drove a meaningful shift of workspace reservations away from the desktop platform, improved booking speed and clarity, and gave the client a scalable foundation ready for further feature expansions. - **2** — Native platforms — iOS & Android - **5** — Languages supported - **100%** — Feature parity with the web platform - UX Research - Native iOS Development - Native Android Development - Localization (5 languages) - QA & Testing - API Integration ### Related --- ## Shaping the Future of Nuclear Medicine Workforce URL: https://meetbrackets.com/case-studies/inspire-by-eanm Client: EANM Categories: healthcare > Turning a technical field into an engaging, playful platform to attract the next generation. ### Overview #### As Europe's largest non-profit dedicated to advancing nuclear medicine, the European Association of Nuclear Medicine launched Inspire to attract and motivate young people to pursue careers in this important field. ### The Challenge ##### Design a modern, innovative platform to attract younger audiences to a field often perceived as "too technical" or "boring." The goal was to shift perceptions of nuclear medicine — from overly clinical and intimidating to inspiring and future-oriented — and build a platform that motivates the next generation to explore it as a viable career path. ### Our Approach - **Creative Concept** — We crafted a unique visual language centered around atoms, playful animations, and custom icons — designed to make the topic approachable and engaging. - **Design & Development** — We delivered the full UX/UI design and front-end implementation, while collaborating with [TRIAD](https://triad.sk/) on backend development and creative direction. - **User Engagement** — To connect with the target audience, we designed an interactive quiz that guides users toward discovering their ideal career pathway in nuclear medicine. - **Iterative Collaboration** — Over several months, teams from BRACKETS, [TRIAD](https://triad.sk/), and EANM worked closely together through numerous design iterations to ensure every detail aligned with the client's vision. ### The Solution ##### A creative concept built around the idea of atoms — dynamic, playful, and instantly recognizable. We anchored the visual identity in the atomic structure and supported it with a dynamic communication strategy, playful animations, and a custom set of pixelated icons that reinforce the brand's youthful spirit. An interactive career-pathway quiz turned passive readers into active explorers, helping users discover where they might fit in nuclear medicine. ### Key Results - **Reframed Perception** — The platform successfully made nuclear medicine more accessible, playful, and appealing for a younger demographic. - **Increased Awareness** — A unique, tailor-made design helped strengthen brand awareness and spotlight nuclear medicine as a viable career choice. - **Strong Collaboration** — Close teamwork across agencies and with the client ensured the final product exceeded expectations. ### What We Delivered - UX/UI Design - Front-end Development - Research & Analysis - Interactive Quiz - Custom Icon Set - Motion & Animations ### In Production ### Testimonial ### Related --- ## AI-Powered Running Technique Analysis URL: https://meetbrackets.com/case-studies/ai-running-technique-analysis Client: Runology Categories: mobile-app ### Overview #### A mobile platform that turns a simple running video into detailed biomechanical insights — helping athletes train smarter and reduce injury risk. ### The Situation ##### Professional running analysis was reserved for elite athletes and expensive labs. For most runners, improving technique meant either hiring a coach, visiting a specialized sports center, or simply guessing what to fix. Biomechanical analysis — the kind that tracks joint angles, body posture, and movement phases — required expensive equipment and trained professionals to interpret the results. Runology set out to change that. The vision was clear: give every runner access to the same quality of technique analysis that professional athletes get — using nothing more than a smartphone camera. ### The Real Problem ##### Recording a video is easy. Turning it into actionable insights at scale is not. The real challenge wasn't the AI itself — it was everything around it. Each uploaded video needed to be processed through an AI engine, enriched with skeleton overlays, phase markers, and angle measurements, then cut into segments with slow-motion highlights. All within 20–30 minutes. Now multiply that by dozens of users uploading simultaneously. The platform had to handle unpredictable spikes in demand while keeping costs low enough to offer affordable pricing — all without compromising the quality of visual feedback that makes the analysis genuinely useful. ### Key Decisions - **Serverless Video Pipeline** — Each analysis runs independently in the cloud, scaling automatically with demand. No servers to manage, no bottlenecks when dozens of runners upload at the same time. - **AI-Driven Biomechanics** — The platform tracks key body points — knees, shins, feet — measuring angles at critical moments and comparing them against optimal movement patterns. - **Rich Visual Feedback** — Results go beyond numbers. Skeleton overlays, running phase markers, and angle visualizations are rendered directly onto the video — making insights intuitive and actionable. - **Sub-Dime Unit Economics** — The entire video processing pipeline costs under €0.10 per analysis, enabling an accessible price point for everyday athletes. ### The Outcome ##### Professional-grade analysis, available to anyone with a phone. Runology turned biomechanical running analysis from a specialized lab service into something any runner can access in minutes. Record a video, upload it, and receive a detailed breakdown of your technique — complete with visual overlays that show exactly what to improve. The serverless architecture means the platform scales effortlessly with growing demand while keeping operational costs minimal. For runners, it's a personal coach in their pocket. For Runology, it's a scalable product with strong unit economics built into its DNA. - **< €0.10** — Cost per video analysis - **20–30 min** — Processing time per video - **2** — Platforms (iOS & Android) ### Testimonial ### Related --- ## From Reporting Tool to Broker Community Hub Across Six Countries URL: https://meetbrackets.com/case-studies/business-partners-mobile-application Client: Winners Group Categories: fintech, mobile-app ### Overview #### End-to-end rework of an internal broker application — transforming a one-way reporting tool into a community-driven platform with an embedded social network, serving business partners across six countries. ### The Situation ##### An established broker network running on an outdated internal tool. Winners Group, a financial services institution with over 16 years of experience, operates across six countries in the CEE/SEE region — Slovakia, Bulgaria, Ukraine, North Macedonia, Poland, and Romania. Through their network of business partners and specialized advisors, they provide end customers with insurance, mortgages, leasing, real estate, savings and investment services, and risk management. The client already had an internal application used by their brokers. It served as a communication and information channel — keeping business partners informed about their achieved results and supporting day-to-day internal communication. Functional, but limited to one-way reporting. ### The Vision ##### Beyond reporting — building a broker community hub. The ambition was bigger than a rework. Winners Group wanted to turn the application into a community hub by embedding a mini social network directly into it — strengthening the bonds within their broker community, lifting engagement, and giving every business partner a clearer view of their own and shared achievements across all markets. The new solution had to support multiple countries with different requirements within a single application, avoiding the need for separate apps per country. A platform that connects, motivates, and scales. ### Key Decisions - **Product Discovery & Analysis** — Start by mapping the needs of the broker community, their workflows, and the desired social and community dynamics — shaping a clear product direction before writing a line of code. - **Full-Stack Mobile Delivery** — Own the entire product — iOS and Android applications, backend services, and a backoffice system supporting the client's internal operations, content management, and broker-facing functionality. - **Core System Integration** — Connect the application to InsuranceContractManager — the client's brokerage system — so that performance data and contract information flow directly from the system of record into the broker-facing experience. - **Multi-Country Architecture** — Rather than building separate applications per market, design a single application capable of supporting country-specific requirements across all markets where Winners Group operates. ### The Outcome ##### A strategic asset that connects, motivates, and scales. The reworked application gives Winners Group a modern internal platform that combines productivity, transparency, and community in one place. The embedded mini social network transforms the app from a one-way information channel into an interactive space where brokers connect and share achievements. Internal communication now flows through a single, consistent channel reaching brokers across all markets. Visibility into individual and shared results supports a performance-driven culture, while the multi-country architecture makes future market expansion significantly easier. By combining product discovery, full-stack delivery, and deep integration with the client's existing infrastructure, the application has become a strategic asset — one that strengthens the broker community today and supports Winners Group's international ambitions tomorrow. - **6** — Countries supported - **2** — Platforms (iOS & Android) - **1** — Broker community platform ### Related --- ## Create Beautiful Admin Panel Quickly URL: https://meetbrackets.com/case-studies/create-beautiful-admin-panel-quickly Client: CraftablePRO Categories: other ### Overview #### A Laravel-based CRUD generator built by developers, for developers. Speed up the development of admin panels, CMS, CRM or other back-office systems — without sacrificing quality or flexibility. ### The Challenge ##### Every new project started with the same repetitive work. Developers rebuild the same CRUD interfaces, user management, permissions, and media handling for every project. Hours spent on boilerplate instead of unique business logic. The result — wasted time, inconsistent code, and higher costs for clients. ### Our Approach ##### We packaged years of Laravel expertise into a single toolkit. Instead of rebuilding admin panels from scratch, we created a generator that scaffolds complete CRUD modules with validation, permissions, and a polished UI. Two commands to install. Zero config to start. Built on Vue 3 and Tailwind with a full Storybook component library. ### Key Features - **Beautiful UI** — Clean, minimalistic interface built with Vue 3 and Tailwind. Full Storybook component library included. - **Roles & Permissions** — Robust access control system for CMS, CRM, web apps and mobile applications. - **Modules Generator** — Scaffold complete CRUD modules with validation rules in seconds. - **Localization** — Multilingual content creation with a built-in translatable strings manager. ### The Impact ##### From days of setup to minutes. What used to take days of repetitive coding now takes two CLI commands. Developers focus on business logic, not boilerplate. The toolkit powers admin panels across dozens of projects — from small CMS to enterprise CRM systems. ### Related --- ## Revolutionizing Agency Management URL: https://meetbrackets.com/case-studies/revolutionizing-agency-management Client: Allfred Categories: crm, fintech ### Overview #### An all-in-one agency management platform that transforms how advertising agencies operate by combining project, finance, and management functions into a single solution. ### Challenge Meets Opportunity ##### Advertising agencies juggle project management, budgeting, and resource allocation across dozens of tools. The complexity of running an agency — from tracking time and budgets to managing teams and client expectations — was spread across disconnected systems. This fragmentation led to inefficiencies, miscommunication, and lost revenue opportunities. Allfred was designed to address these complexities head-on, streamlining operations and fostering collaboration across every department. ### Innovative Engineering and Design ##### Built with a cutting-edge tech stack and agile methodologies. The focus was on creating intuitive interfaces that agency teams could adopt without friction. Every feature — from resource planning and time tracking to budget management and comprehensive reporting — was crafted to feel natural and powerful at the same time. Developed collaboratively with BRACKETS, the platform went through continuous iteration cycles, ensuring each release delivered measurable value to agency workflows. ### Key Decisions - **Resource Planning** — Centralized resource allocation and capacity planning, giving agencies full visibility into team availability and workload across all projects. - **Time Tracking** — Integrated time tracking that connects directly to budgets and projects, eliminating manual reconciliation and providing real-time profitability insights. - **Budget Management** — End-to-end financial oversight from estimates to invoices, enabling agencies to track margins and control costs at every stage. - **Comprehensive Reporting** — Unified reporting across projects, finances, and resources — turning scattered data into actionable insights for better decision-making. ### Transformative Outcomes ##### Allfred delivered measurable impact across the board. Agency teams saw significant time savings by eliminating manual tasks and consolidating their toolset. Reporting that previously took hours became available in minutes, and project visibility improved dramatically — leading to better financial management and increased profitability for agency users. - **30%** — Savings in time spent on manual tasks - **3×** — Improvement in reporting efficiency - **100%** — Project visibility across teams ### Related --- # Authors ## Pavol Perdík URL: https://meetbrackets.com/author/pavol-perdik CEO at BRACKETS. CEO and founder of BRACKETS, a 20-person digital product studio in Bratislava. 15+ years in tech: started as a developer, grew into technical leadership, now runs the business. Helps clients translate business problems into shippable software, from the first discovery conversation to production. Pavol founded BRACKETS over 10 years ago and has led the studio through 80+ successful projects across healthcare, fintech, e-commerce and enterprise. He started as a developer and CTO, which means he still thinks in systems, but today his focus is on the business side: helping clients figure out what to build, how to scope it, and whether it's worth building at all. His technical background makes him the kind of CEO who can sit in an architecture review and a board meeting on the same day, and add value in both. He's deeply invested in AI, not as hype but as a practical shift in how software gets built and delivered. At BRACKETS, he sets the product strategy, leads client relationships, and makes sure the team stays small enough to care and experienced enough to deliver. His belief: the best software studios don't scale by adding people — they scale by making better decisions earlier. His writing focuses on the intersection of business and technology: when custom software makes more sense than SaaS, how AI changes the economics of software development, and what it actually takes to ship products that matter. Areas of expertise: Product Strategy, Business Development, Technical Leadership, AI Strategy, Software Economics, Client Advisory, Team Building Links: [LinkedIn](https://www.linkedin.com/in/pavolperdik/), [Email](mailto:pavol.perdik@meetbrackets.com) --- ## Samuel Trstenský URL: https://meetbrackets.com/author/samuel-trstensky Solution Architect & Tech Lead at BRACKETS. Solution Architect & Tech Lead at BRACKETS with 8+ years in software engineering. Leads projects from first discovery call to production, bridging what clients need with what the architecture can sustain. BRACKETS' go-to person for AI-driven solutions, both for clients and internal tooling. Samuel approaches every project the same way: understand the real problem before writing a line of code. As Solution Architect, he owns the full arc — from initial discovery calls and scoping through technical specification to hands-on delivery and quality control. Over 8 years he's led teams across healthcare, fintech, logistics and enterprise projects, designing systems that hold up under real-world complexity. His strength is translating business problems into technical architecture that's buildable, maintainable, and honest about trade-offs. He's also the driving force behind AI adoption at BRACKETS. He designs AI-powered solutions for client projects, from intelligent workflows to document processing, and continuously pushes internal processes forward by identifying where AI tooling actually helps and where it doesn't. His writing covers the practical side of engineering leadership: how to keep velocity without accumulating debt, what AI tooling actually changes in delivery, and why the boring architectural decisions matter most. Areas of expertise: Solution Architecture, System Design, Engineering Leadership, AI Tooling, Technical Strategy, Code Quality, Product Discovery, Project Delivery Links: [LinkedIn](https://www.linkedin.com/in/samuel-trstensk%C3%BD-617915193/), [Email](mailto:samuel.trstensky@meetbrackets.com) --- # Articles ## We built a Jira Service Desk copy. Vibe-coded in 3 days. Well, sort of… URL: https://meetbrackets.com/thinking/vibe-coded-service-desk-in-3-days Author: Samuel Trstenský (https://meetbrackets.com/author/samuel-trstensky) Published: Aug 12, 2026 Topic: Engineering Read time: 7 min > Could we vibe-code an entire service desk in a single day? Short answer: it gets you something that looks done. It doesn't get you something that is done. Here is what the day, and the three weeks after it, taught us. ## We built a Jira Service Desk copy. Vibe-coded in 3 days. Well, sort of… A year ago we had a brilliant teambuilding idea. Let's take a break from programming by... programming. The goal: could we vibe-code an entire service desk in a single day? So we split into small teams and started vibecoding. And I mean vibecoding. Not agentic coding, not "AI-driven development." We did it the loose way on purpose, because the real question was: does vibecoding without any proper setup actually work? Short answer: it gets you something that looks done. It doesn't get you something that is done. Here's what the day, and the three weeks after it, taught us. ## Vibecoding doesn't scale across a team The first surprise was how hard it was for us humans to cooperate. With more than one team touching the backend, we spent more time resolving merge conflicts than building features. Vibecoding in a group needs serious coordination, and on a project this small I wouldn't put a team of humans on it at all. A team of AI agents plus one human? Different story, and I'll come back to it. ## Vibecoding without a spec, or a workflow, is a trap Our "specification" was one sentence: we need to build a service desk. Everything else we discovered as we went. Maybe add a Slack integration? Tickets from email? Image upload? Should the client be able to change priority? [That's a perfectly fine way to build a prototype](https://www.linkedin.com/posts/pavolperdik_we-have-a-client-running-their-entire-business-activity-7478055085231521792-RHhX), the kind you throw away once it has taught you what the spec should be. But we didn't want to throw it away, we wanted to build on top of it. So every feature we'd stumbled into had to be retrofitted properly, and that cost us far more time than two hours of spec up front would have. Same story with the workflow. No feedback loop, no dedicated agent for end-to-end tests, none of the plugins and skills we use today. It was fast, sure. But the output isn't comparable to a proper agentic run in terms of bugs, security, or the ability to run unattended. ## It looks like it's done. It isn't. Here's the part I'd underline. Getting from the hackathon to a first real MVP took me about two more days: fixing what the vibecoding left behind, refactoring the roughest parts into something maintainable. And it worked. A service desk MVP in roughly three days is a solid result, and it was real enough that we onboarded a few early clients on it. Then the clients started using it, and we spent almost three more weeks before we were happy with the core. So where did those three weeks go? Two places, and both were avoidable. Part of it was features and refinements that only surfaced once clients were in the tool. That sounds like unavoidable product discovery, but it wasn't. A few hours of proper brainstorming up front, plus a little research with the people who'd actually use it, would have surfaced most of those before we wrote a single line. We skipped that thinking, so the tool told us later, the expensive way. The other part was bugs. That's what plain vibecoding gives you when nothing is reviewing the work and nothing is testing the UI: it looks great in the demo and then falls over in real use. Those aren't specification problems, they're workflow problems, and they're exactly what a proper agentic loop, with a reviewer and an e2e tester, catches before anything reaches a client. So the three weeks weren't a mystery. They were the bill for skipping two things: the thinking and the workflow. Do both properly up front and most of that time never gets spent. ## How we'd do it now: agentic coding That hackathon was fun (mostly). We vibecoded, drank beer, and turned out a decent result given the circumstances 😄. Today we'd do almost none of it the same way (except for the beer, of course 🍻). Two things changed everything, and both now live in a plugin the whole team can install from our internal Claude Code marketplace ([I posted about it on LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7472924356260626434/), in Slovak). **Specification first.** I say this in every article and I'll keep saying it because it keeps being true: the spec is the most important part now. You can spend more time writing the specification than writing (generating) the code, and that's completely fine. For something the size of the service desk, the plugin includes a `/draft-spec` skill that walks us through it, so we can go from idea to a real spec quickly, whether it's a whole system or a single new module on an existing one. **A real workflow, not just a chat window.** Typing into Claude Code or Codex and hoping (with fingers crossed) is not a workflow. The rest of the plugin is the workflow itself, and it looks like this: 1. Split the spec into tasks. Our `/plan-backlog` skill breaks the spec into individual tasks and creates a `progress.md` file that tracks progress automatically. 1. Work the tasks in a loop. We call `/loop /next-task`, and the loop keeps pulling the next task until the queue is empty. 1. Inside each task, a small team of agents does the work: an Implementer writes it, a Reviewer checks it, and an E2E tester actually drives the UI (AI loves to ship a broken interface, so this one earns its keep). The Reviewer and the tester can hand a task back to the Implementer if something's off. 1. Task done, next task pulled. The point is what it did to the output: the quality jumped enormously. And I have proof. We decided to replace the rest of Jira, too. Because why not 😄. Phase one meant adding a Backlog, a Kanban board, time tracking, and a bit of a redesign. This time we ran it through the real agentic workflow: proper spec, split into tasks, each task built by the team of agents with a feedback loop. The result? Three days, feature deployed. One day on the spec, one day reviewing the PRs and sending feedback, and roughly five or six hours in between where the agents worked the backlog unattended. Two of the three days were human work. The agents ran on their own for an afternoon. Same three days as the hackathon. Different three days, though. The first sprint shipped a real MVP, then charged us for everything we'd skipped: the thinking and the workflow. The second one shipped and stayed shipped, because both happened before the code, not after it. One honest caveat, because it matters: this isn't "leave for the weekend and let the robots ship to production." We plan for a couple of hours, kick off the workflow, and come back to a stack of open PRs. A human reads them and reviews before anything merges. The agents do the heavy lifting. A person still owns what goes out the door. So if you take one thing from our beer-powered hackathon: when you're picking a partner for a production app, look for the ones running an agentic workflow, not the ones vibecoding your product on vibes. ;) --- ## What legacy code migration actually costs in the AI era URL: https://meetbrackets.com/thinking/legacy-code-migration-cost Author: Samuel Trstenský (https://meetbrackets.com/author/samuel-trstensky) Published: Jul 21, 2026 Topic: Engineering Read time: 6 min > Vendor lock-in was never a contract. It was the cost of moving your code, and that just collapsed. Here is how we take over a legacy codebase now, and where it still bites. ## What legacy code migration actually costs in the AI era *Vendor lock-in was never really about the vendor. It was about the cost of moving the code. That cost just collapsed.* Rewind to 2024, before AI changed how we build software. Back then, when a client asked us to take over software another studio had built, we never flatly refused. But we were upfront: this is going to be painful, and it will cost more than you're hoping. That was the honest read, not caution for its own sake. Taking over someone else's codebase was genuinely, expensively hard, and we knew it going in. Understanding it, refactoring it, reconstructing the documentation from the code could eat weeks before we shipped anything new. We priced that reality in, and plenty of clients decided it wasn't worth it. That cost was also the exact thing keeping you stuck with a vendor you'd outgrown. ## The trap that keeps you with the wrong vendor Look at that same moment from the client's side. A studio built something business-critical for you, and the relationship has gone sideways. Maybe the project outgrew them. Maybe it was one freelancer who no longer has time for you. Maybe they raised prices because they knew you couldn't easily leave. So you decide to move. You call other studios. And you discover it is not that easy. Almost everyone is reluctant to take over existing code, for one or more of these reasons: 1. They lack the domain knowledge the original team built up over years. 1. The code is bad because it was written that way. 1. The code is bad because it was transpiled or obfuscated, deliberately harder for anyone else to work with. 1. There is no documentation. Every one of those reasons is real. Understanding, refactoring, and documenting an unfamiliar codebase could take weeks before you shipped a single new feature. So you're told the honest thing: this needs a rewrite, and it will cost a lot. You go back to your original vendor, quietly stuck. > “The real vendor-lock is not a contract. It's actually the cost of moving your code. Not anymore.” ## What changed Here is the shift. In AI-driven development, documentation is everything, and documentation no longer has to be something a human sat down and wrote. AI can read code, including legacy code it has never seen, and turn it into human-readable explanation. That one capability unlocks the rest. We can now: 1. Generate domain documentation from the logic buried in a legacy codebase. 1. Refactor bad code, whether it was written badly or transpiled that way. 1. Move code onto a different stack. 1. Generate technical documentation for the code itself. The practical result: the cost of taking over a codebase dropped to a fraction of what it was. What was previously unreasonable to refactor (due to the high costs) is now completely unlocked. For me, the bigger unlock was that we stopped being limited by stack. A system written in something we'd never shipped in is no longer an automatic no, because we can rewrite it into a more stable and familiar stack that we can maintain for years to come. ## Why you can believe that "AI makes legacy takeover easy" is exactly the sentence every agency is about to start saying. So here is what we actually do, because a workflow is harder to fake than a claim. **We document the domain before we touch anything.** A human on our side has to understand what the system does and why, so we can make the judgment calls when the AI can't. We run a dedicated Claude skill across the legacy codebase that documents each module and its logic. The output is effectively a domain guide: the principles of the system, reconstructed from the code that implements them. **We split the work, then loop it through specialised agents.** Refactoring or re-platforming runs as a structured process: 1. Analyse the codebase and break it into modules, the functional groups of code. In a CRM, "Contacts" is a module. 1. Break each module into concrete tasks: rewrite the contacts controllers, the models, the frontend. This splitting is itself part of creating the documentation. 1. A human checks that the tasks are meaningful and the overall architecture holds up. Then each task runs through a loop, with a separate agent for each job: - one implements the task, - one writes backend tests, - one writes end-to-end tests, - one reviews the result, - one runs a parity check: the AI visually compares the refactored screen against the original and calculates the deviation. Any agent in the loop can hand a task back to the implementer to fix what it found. We tune the allowed deviation deliberately, around 5% for example, because chasing a pixel-perfect match on margins and padding is a good way to loop forever for no real gain. **A human closes the loop.** At the end we review the migration, walk through everything the agents flagged, and often spin up a few more tasks based on what we find before going back around. Notice the shape of it: AI does the volume, humans own the judgment at both ends. That is the whole reason it produces something maintainable instead of a pile of plausible-looking code. A recent one, which I'll keep vague because it's under NDA: an unfamiliar codebase of around 10 modules and roughly 50 screens, moved onto a completely different stack. Five days. Done the old way, understanding it, re-platforming it, testing every screen by hand, that is several months of work. That gap is the entire point. ## Where it still bites The honest limitation, and it is a real one: this workflow handles bad code well. It does not automatically handle *wrong* code. If the legacy system isn't just messy but logically incorrect, a calculation that has been quietly wrong for years, the AI has no way to know whether that's a bug or your intended, if unusual, business rule. Left alone, it will faithfully carry the mistake into the new system. So before we refactor, we hunt for those gaps first: the miscalculations, the logic that doesn't add up. We fold the fixes into the tasks, so what comes out is correct, not a cleaner copy of the same error. ## The takeaway If you're staying with a vendor you've outgrown because moving feels too expensive, that math is out of date. What used to be an expensive blocker, and a very effective form of lock-in, is now a manageable, mostly one-time cost. An old stack, unmaintainable code, a team that stopped caring: none of it has to be permanent anymore. If you've got a codebase like that, we'll do a free audit, tell you honestly what shape it's in, and give you a price for taking it over along with the next steps. No rewrite-from-scratch reflex. Just an honest read on what it takes to get you unstuck. [Let us know!](https://meetbrackets.com/contact) --- ## The Boring End of SaaS URL: https://meetbrackets.com/thinking/the-boring-end-of-saas Author: Pavol Perdík (https://meetbrackets.com/author/pavol-perdik) Published: Jul 7, 2026 Topic: Strategy Read time: 3 min > Everyone predicts SaaS is dead. I think the truth is more boring: it splits in two. Here is the build-vs-buy math that flipped, and what it means for your next renewal. ## **The boring end of SaaS** "The end of SaaS." I've been hearing this for two years now. The price of writing software has collapsed, so why would anyone pay for a generic tool when they can have their own. Tailored (literally) to how they work, with no subscription attached? I keep changing my mind about it. Some days I'm certain. Why would any company pay for software that does things in a way that doesn't fit their actual process, that people need to adapt to and not the other way around? The economics that used to justify it are gone. Other days I look at how slowly companies actually change. How much momentum and habit and risk-aversion sits inside every tooling decision. Then I'm certain of the opposite. AI brought genuine disruption, and disruption makes us reach for extreme predictions first. SaaS is dead. Everyone will build everything. The reality is going to be more subtle, more boring than that. Most likely, two things happen in parallel. Both driven by the same cause: writing software got dramatically cheaper. ## **Stream one: extreme customization** There have always been companies that ran the math on SaaS versus custom and chose custom. What changed is where the break-even sits. It's not just the subscription cost. It's the cost of running a suboptimal process because your tool doesn't support the way you actually work. That second cost is usually the bigger one, and it never shows up on an invoice. Imagine every company running its own CRM. Maybe built around a shared core, but genuinely built for them. Wait, I don't mean "customized" through configuration screens or anything like that. I mean really: **built for them**. That's a mindset shift, not a feature comparison. And the economics now allow it. ## **Stream two: affordable software** One day I was reviewing our SaaS bill and stopped at one line: Jira Service Desk, around €4,000 a year. We used it for one thing: giving customers a portal to report tickets. The pricing made no sense next to regular Jira, and I'm sure it's full of features we never touched. So we built our own service desk. This was software we'd relied on for eight years. Now completely replaced, in two months. Here's the thing about SaaS pricing: growth mindset runs subscriptions up. Product teams keep shipping features, companies keep chasing expansion revenue, and the price follows — whether or not you need any of it. With AI, we should expect the opposite force. Small, skilled teams will build focused copies of existing SaaS. Equally good. Or maybe simpler and better at one thing. But at **dramatically lower cost**. The reason this didn't happen before is that the entry cost was too high. It isn't anymore. By the way: after the service desk, we replaced Jira itself. Another €2,000 a year. Sorry, Atlassian. ## **The boring conclusion** So no, I don't think SaaS ends. I think it splits. Companies with specific workflows will increasingly [own their software](https://meetbrackets.com/own), because tailored finally beats generic on price. And the SaaS that survives will face real competition from affordable challengers, because the moat of expensive initial development is gone. Neither stream is dramatic. Both are already happening. The interesting work is knowing which side of the split a given tool belongs on. And running that math before the next renewal. --- ## Vibe Coding Is for Thinking. Agentic Engineering Is for Shipping. URL: https://meetbrackets.com/thinking/vibe-coding-vs-agentic-engineering-what-actually-changes-when-you-ship Author: Pavol Perdík (https://meetbrackets.com/author/pavol-perdik) Published: Jun 30, 2026 Topic: Engineering Read time: 5 min > For months I used the two terms interchangeably. Most people still do. They are not the same activity, and the difference shows up the moment you put either one into production. ## Vibe Coding vs Agentic Engineering: What Actually Changes When You Ship For a while I used the two terms interchangeably. Most people still do. They sound like the same activity with different branding: a human and an AI making software together, fast. They are not the same activity. They produce different code, in different ways, with very different consequences. We run one of them in production now, on real client work. It took us a while to understand why the other one keeps ending in tears. Here is the difference, in three parts. ### Part I: One you get attached to. The other you throw away. Vibe coding is when you stay up until 2am watching something work and having no idea why. It feels like magic. And because it feels like magic, you get attached to it. So when it breaks, you try to fix it. You patch the patch. You do, then you wait, then you fix, because throwing it away feels like losing something you made. Agentic engineering takes that attachment out, on purpose. The current wave of agentic development is built around two things: loops and a harness. The loop is the agent working through tasks on its own, again and again, while you do something else. The harness is everything wrapped around that loop to keep it honest: code styling rules, frontend conventions, security checks, a PR reviewer agent, and a human on the final review. Once you trust the harness, you stop caring about any single run. I wake up to fifteen open pull requests. I open a few. I see the agent reached for something we would never ship, or solved a problem in a way that ignores our patterns. So I bin the whole thing and regenerate. No grief. Even if half the overnight tokens are gone with it. In vibe coding you fix because you are attached. In agentic engineering, trash and regenerate is the default. (At least while tokens are cheap. That math may change.) ### Part II: One is for thinking. The other is for building. This is the part people miss, and it is in fact the part that makes me defend vibe coding rather than dismiss it. Vibe coding is genuinely useful. Not for shipping, but for reasoning. You explore the problem by building a rough version of it. You find out what you actually want by watching a bad version of it run. It is a pencil and paper for a builder. The thinking happens through the making. Agentic engineering is closer to traditional software development than it is to that. You do the thinking first, away from the keyboard. You decide what to build, how it should look, what the architecture is, the exact user journeys, the screens, sometimes down to the buttons. Then you hand that to the agents. The workflow we use now looks like this. I have a conversation or a meeting with a colleague about a project. I dictate to Claude to pull the transcript, summarise it, and write a brief. Then I spend time with that brief. This is the important step, and it can take minutes, hours, or occasionally days. When the brief is right, I hand it to a Claude Code skill we built. It reads the brief, structures its own docs, breaks the work into tasks, and loops over them while I am asleep or doing something else. The agents are fast. The thinking in front of them is still slow, and it is still mine. The speed at the end is only ever as good as the clarity at the start. ### Part III: One does not scale. The other is how we ship now. Vibe coding is fine for a prototype. It is fine for a throwaway internal tool nobody really depends on. It is not fine for a business core system. We have a client right now running their entire operation on a vibe-coded solution. I will be direct about it: it is not good. It is full of bugs the original dev shop cannot fix, because the code underneath is a mess. They fix one thing and break two others. There were no standard practices anywhere in it. No PR reviews. No end to end tests. No security audit. It works until it doesn't, and then nobody can tell you why. Agentic engineering is the opposite, because it does not throw away the last twenty years of software engineering. It uses AI inside that discipline, not instead of it. You build [an architecture of agents, skills, and plugins that work together](https://meetbrackets.com/accelerate). The point is not to bypass the humans. The point is to make a small number of senior people far more capable than they were. The results are not subtle. Spec to production now takes days, where it used to take weeks or months. That cuts the cost of building. And when it is done right, with the harness in place, it raises the quality bar rather than lowering it, because the checks never get tired and never skip a step under deadline. So we are building more than we ever have. At a standard we are comfortable putting our name on. ## TL;DR version Vibe coding is a way to think with code. Agentic engineering is a way to ship with it. One is a sketchpad. The other is a workshop with rules. The mistake is handing someone the sketch and calling it the building. --- ## From hero to zero: why we're replacing every SaaS tool we built on top of URL: https://meetbrackets.com/thinking/from-hero-to-zero-why-we-re-replacing-every-saa-s-tool-we-built-on-top-of Author: Samuel Trstenský (https://meetbrackets.com/author/samuel-trstensky) Published: May 26, 2026 Topic: Engineering Read time: 5 min > We spent 18 months building on SaaS tools. Now we're ripping them out. Here's what broke and why I'd do it differently today. This month, we're turning off the last SaaS tool in a system we spent 18 months building. When we started, those tools were the hero of the architecture. Today, they're the part we're ripping out. Here's how we got there, and why I'd probably do it differently if I started the same project today. ## How we got here A year and a half ago, we had a discovery meeting with a client in the health sector. They walked us through their workflows, the tools they were using, and how everything connected. What astonished us wasn't the complexity itself, but the fact that non-technical people had built something this functional out of off-the-shelf tools. Zapier, Typeform, Salesmate… A real hero, [glued together from SaaS tools](https://meetbrackets.com/thinking/your-business-is-unique-your-software-should-be-too). Our job was to build a central system on top of all of that. A customer-facing portal that connects the existing tools and makes the experience self-serviceable. The way health clinics actually work is more complicated than you'd think :D, but at the time the plan was straightforward: keep the SaaS tools, build the portal around them, integrate the gaps. At first, we thought leaning on those tools would make our life easier. And for the first release, it did. ## The real problem: you inherit every limitation of every tool Here's what we underestimated. When you build a central system that depends on five SaaS tools, you don't just integrate five APIs. You inherit five sets of limitations. Every workaround in every tool becomes a workaround in your system. Every quirk, every blackbox behaviour, every missing capability, every release schedule you don't control, all of it now lives in your stack. And there's no engineering discipline that can mitigate that. You can't refactor your way out of someone else's product decisions. Three things broke us over the 18 months, all flowing from this one root. ### Three sources of truth The central entity in these workflows was the product. We needed to have products in at least two of the SaaS tools plus our central system. Two sources of truth is already a problem. Three? Imagine the clinic's staff looking at a product in their CRM and seeing the wrong price, while our central system and the customer's checkout show the correct one. The customer is fine. But the staff is now making decisions based on a wrong number, and the analytics they track in that CRM, revenue, conversion, performance per product, are quietly off. The answer was always the same: hope, then check. ### Testing without a net Most SaaS tools don't give you a dev environment. And on top of that, regulated healthcare meant some of the legacy systems in the stack were government-certified, no proper API, no test environment, and no chance of being replaced. So testing turned into hoping. In our dev environment we built fake providers that returned fake outputs, and we had to keep those fakes in sync with what the real tools returned (which was often uncharted territory). In production, we shipped and watched. This is the part a CTO will feel in their stomach. You can't write a meaningful integration test against a system that has no test mode. ### Staff bouncing between login screens The system stopped being just for clients. The clinic's own staff lived in it too. Every time they had to jump from our portal into a differently-looking CRM or form tool, the friction added up. We used SSO where we could, but SSO doesn't fix the fact that you're in a different system, with a different mental model, looking at different buttons. Our goal was to minimise clicks. The SaaS stack maximised them. ## The cost Cost was a major factor too. We'll dig into *SaaS vs custom* economics in a separate piece, but here's the short version: the change over the last 18 months has been enormous. It used to be unthinkable to replace a SaaS tool with a custom build and actually save money. Now it's perfectly possible, and in a lot of cases, it makes complete sense. Once the build cost dropped, every one of the problems above stopped being a tradeoff and started being a tax. ## So, would I do it again? If your central system depends on more than two SaaS tools to support one core workflow, you are inheriting more limitations than you realise. The integration cost is visible. The tax of testing-without-a-net, three-sources-of-truth, and staff-bouncing-between-tools is not, until you've lived it for a year. Run the custom-build math before you sign another renewal. The number you get back will not be the number you got two years ago. If you want a starting point, we wrote up how we think about [replacing SaaS with custom builds](https://meetbrackets.com/own). Would I do this project the same way 18 months ago? Probably. Would I do it the same way today? Almost certainly not. The SaaS-glue start was correct for its moment. The moment changed faster than the architecture did, and that's the part worth paying attention to. --- *Authentic thoughts by human me :). Grammar fixed by AI.* --- ## Your Business Is Unique. Your Software Should Be Too. URL: https://meetbrackets.com/thinking/your-business-is-unique-your-software-should-be-too Author: Pavol Perdík (https://meetbrackets.com/author/pavol-perdik) Published: May 22, 2026 Topic: Strategy Read time: 8 min > For decades, businesses had to adapt their unique workflows to fit the rigid boxes of off-the-shelf SaaS because custom software was a luxury reserved for tech giants. In 2026, AI has permanently bent the software development cost curve. Here is why the old compromises no longer make sense for your operations. Last year a client said something to me I keep thinking about. We were two meetings into the discovery for what became a custom internal platform, and somewhere between the workflow diagram and the third "and then we copy that into Excel" beat, he stopped. He looked at the wall. He said: "Honestly, I didn't even realize we could have a system for this." He'd been running his business that way for a decade. Across more tools than he'd like to count. Across more spreadsheets than I'd like to count. With most of the real decisions happening in a Slack channel that their CRM didn't track. (Real story. Multiple companies. Same channel.) It's not that he'd thought about custom software development and rejected it. He'd never thought about it at all. Like most of the world, he'd accepted the friction as the cost of running a business. The way you accept that your bank app asks you to confirm three times. The way you accept that your reporting tool can't actually do the report you want. You shrug. You [build a workaround](https://meetbrackets.com/thinking/from-hero-to-zero-why-we-re-replacing-every-saa-s-tool-we-built-on-top-of). You move on. I want to talk about that shrug. Because I think 2026 is the year it stops making sense. ## The Hidden Cost of Rigid Off-the-Shelf SaaS Three Excel sheets. Two SaaS subscriptions. A Slack channel where the real decisions get made. That's not the worst case. That's the median. Not the version on the website, where the workflow diagram has clean arrows and the tools talk to each other. The real version. The one where Jana from sales emails Marek from finance a screenshot because the CRM doesn't talk to the invoicing tool, and where the "process" lives in someone's head and gets re-explained every time a new hire joins. The diagram is the brochure. The Slack channel is the truth. I know what you're thinking. That's just how it is. And for a long time, you'd have been right. For decades, custom enterprise software was for giants. SAP. Oracle. Bespoke ERP rollouts that took two years and cost more than a small office building. If you weren't a Fortune 500, you didn't get tailored software. You got SaaS. You got the version somebody else built for somebody else's process, and you contorted yours to match. That deal was actually fine for a long time. Better than nothing. Better than Excel. The integrations were rough but they were there. The features were 30% relevant to you but the 30% was useful. Everyone settled. The whole market settled. And here's the thing about settling: you stop seeing what you settled for. We've all been adapting to software for so long we stopped noticing we were doing it. The Slack workarounds. The double data entry. The "we don't really use that part." The reports that take a person three hours every Monday because the tool can't slice it the way the team needs it sliced. These became the background noise of running a business. They show up in nobody's strategy deck. They're just there. The math has changed. ## How AI Altered the Economics of Custom Software Development I'll be honest. I'd been hearing "[AI will change software development](https://meetbrackets.com/accelerate)" for two years before I started believing it. Most of the early demos were toy stuff. Code completion got a little faster. Generate me a landing page. Whatever. The shift wasn't a moment. It was a slope. Somewhere in the last twelve months, the cost of building a tailored system for a real company (the kind that integrates with your existing stuff, respects your real workflow, handles your actual edge cases) fell off a cliff. Not for every kind of software (I'll come back to this in upcoming article). But for internal tools, operational workflow automation, and custom platforms that serve a specific business? The math is different now. What used to take six months and a senior team now takes six weeks. What used to need board approval now needs a sane line item. "We'll build the thing that fits you" stopped being theoretical for almost any company above a certain size. (I'm being careful here. AI didn't make all software cheap. Pixel-perfect custom-brand frontends, novel design work, the truly hard creative parts: those didn't get dramatically cheaper. The shift is most visible in internal systems, operational platforms, integrations with legacy stuff. Which, conveniently, is exactly where the friction lives.) ## Tailored Systems in Practice: Three Case Studies Three quick ones. **Our Internal Service Desk.** We were paying Atlassian over €3,000 a year for Jira Service Desk. It did the job, mostly. The job had specific gaps for how we work, gaps Atlassian wasn't going to close in any timeframe I could plan around. Over a hackathon weekend, we built our own alternative. It does what Jira did, plus a few things Jira wouldn't. Slack-native flows. An AI agent that actually understands our codebase through MCP and writes pull requests for a human to review. We didn't switch tools. We stopped having a tool problem. **Dr. Max (The Pharmacy Chain).** They came to us with a different kind of pain. Not a SaaS bill, just a mess. Operations spread across spreadsheets, manual processes, a quiet feeling that nobody had the whole picture. They weren't looking for a solution. They didn't know there was one. We sat in the meetings. We listened. We built something that maps to how they actually run, not how a generic platform would have them run. The system isn't impressive in a screenshot. It's impressive in a Tuesday morning standup, when people stopped re-explaining things to each other. **Calma (The Medical Clinic).** Calma needed a reservation system that played nicely with their CRM and with a legacy patient-records platform they're legally required to use. The legacy database part is the interesting bit. Building a clean API integration with that system used to be the kind of project that made everyone in the room exhale slowly and ask if there was really no other option. Now it's a project. With a price tag that makes sense. With a timeline you can plan around. Three companies. Three completely different shapes of pain. One pattern. ## SaaS vs Custom Software: What This Means for You If you've been recognizing yourself somewhere in the Excel-sheets-and-Slack picture, here's the honest version. Every company is unique. Yours is no exception. The way your sales team qualifies leads, the way your operations team handles exceptions, the order in which approvals actually happen versus the order they're supposed to happen: that's your business. That's what your team gets paid to be good at. There's no reason your software should be telling you how to do that. Especially now. What can be automated should be automated. The boring stuff. The repetitive stuff. The "we have to do this every Monday and nobody knows why" stuff. The data entry that exists only because two tools don't talk to each other. The workflows that exist only because the tool didn't anticipate your case. These were rational compromises five years ago. They're getting less rational every quarter. Your software should serve you. Not the other way around. ## Who This Alternative Paradigm Is Not For A caveat, because the internet is a place and I don't want anyone reading this and immediately filing a help ticket against their HubSpot or Jira accounts. If you're a five-person company on Slack free and a HubSpot Starter, this article isn't for you. Stay where you are. Pay the small bill. Build your business. (Come back when the workflow starts hurting.) If you're a solo founder using Notion as a CRM and you've never paid more than $20/month for a single tool, also not you. Commissioning a custom platform right now would be one of the most expensive procrastination strategies available to a founder. And there are many. The math in this piece kicks in somewhere around the point where your annual SaaS bill has its own line item in the P&L. If you're not there yet, file this away for later. If you're not sure which side of that line you're on, we built a short check for it. Five questions about the tool you pay for, and you get our read on whether replacing it makes sense. No call, no deck. [Run the SaaS Check](https://meetbrackets.com/tools/saas-check). ## Weighing the Financial Return on Investment I haven't really talked about cost here, on purpose. Custom software used to be expensive both ways: too expensive to build, and over the SaaS bill's lifetime, too expensive to rent. The first part just changed. The second part has been changing too, for some companies. If you're also wondering whether owning your software saves you money on the SaaS line, that's a separate conversation, and I wrote it up in [The Boring End of SaaS](https://meetbrackets.com/thinking/the-boring-end-of-saas). But money isn't the reason most of our clients are doing this now. Fit is. For a long time, the smart move was simply to adapt. Software was expensive, off-the-shelf was acceptable, and a clever workaround beat a custom build almost every time. We built our company on that math. We told clients to use HubSpot and integrate. We helped them set up Pipedrive. We were right. We're not right anymore. Not always. Not for the cases where the friction has been quietly costing real money the whole time. [Your software should fit you](https://meetbrackets.com/own). Now it finally can. --- ## I Don't Write Code Anymore. So What Do I Actually Do? URL: https://meetbrackets.com/thinking/i-dont-write-code-anymore Author: Samuel Trstenský (https://meetbrackets.com/author/samuel-trstensky) Published: May 12, 2025 Topic: Engineering Read time: 8 min > I uninstalled my code editor. AI agents handle the typing now. Here's what my day actually looks like and why the thinking part matters more than ever. It was a year and a half ago when we started our first project with an AI-first approach. Sonnet 3.5 was the best coding model at the time (at least based on our limited experience back then), and we decided it was mature enough to delegate all the non-critical logic to. Complex logic still needed to be done manually, but the vast majority of tasks were already good enough quality to save developers a nontrivial amount of time. Some developers were skeptical, but luckily everyone at Brackets is curious by nature, and we all spent time exploring tooling, models, and approaches. Fast forward to today: there is no project without an AI-heavy approach. Programming as we knew it is becoming more automated by the week, and the number of lines I write the old-school way is getting close to zero. So if I don't code, what do I actually do? ## New workflow in the AI era I always enjoyed problem solving. Designing the approach, evaluating possible solutions, figuring out how to do it within constraints of time, budget, and scope. Coding it afterwards was never my favourite part. Two years ago, my work was 20% problem solving and 80% coding what had been brainstormed. Today it's closer to 50/50. And the ratio keeps shifting. So what are the key things I do? ## Brainstorming with client We were developing a project for the European Association of Nuclear Medicine, and I remember that before every call with the client, my PM was reconsidering whether it was worth having me there. Somebody needed to code the solution. We didn't want to "waste" my time on calls. I was always against it. I wanted to be on those calls, because I had insights the PM didn't. I knew how the database was structured. I knew there was a better and cheaper solution than what was being proposed. The PM couldn't know that. And why would they, it's not their job to know the schema. This is what I consider the single best thing AI models gave us. Developers can finally redirect their problem-solving minds to actually solving client problems, rather than coding an already-solved problem (often worse than it could be, because the architect wasn't on the call). ## Scope and project definition Once the brainstorming sessions are done, I need to put the ideas and solutions into a project scope and definition. This is a crucial step. It needs to be crystal clear what was agreed on. This existed before AI and will always exist. But in the past, remembering everything we agreed on wasn't always easy. And I hate making notes during meetings. It takes my focus from the important part: the actual brainstorming. For more than a year now, we've been using Fireflies in our meetings, which transcribes all our brainstorming sessions. Generating a project scope is then a matter of one prompt: "Take my last 3 meetings with X and create a project scope and definition." Our preprepared Claude skills handle the rest. Again a lot of time saved. I focus only on what matters most: reviewing whether the proposition actually solves the problem, rather than writing the whole document myself. It often happens that AI puts too much weight on parts that aren't that important, while missing the things that matter most to the client. AI can't read the room in a brainstorming meeting. It doesn't pick up on the moment when the client's voice shifts, when they lean in on a topic, when they gloss over something they don't care about. That's a purely human skill, and that's why a human in the loop isn't optional. It's the whole point. ## Brainstorm again After the document is ready, we go through it with the client to make sure we're on the same page and all problems are addressed. This is an iterative process, and that's a good thing. It has to be iterative, because… ## A good plan is everything The next step is generating technical tasks from the project brief. Either in Jira, or in my case, I prefer markdown files directly in the project repository. It works much better for AI coding agents to have all project scope (spec, PRD, …) directly within the codebase. Agents will understand it significantly better, which improves maintainability, and as a bonus, it becomes your documentation. The core responsibility of the developer at this stage is to deeply review the generated tasks. Is the design correct? Is the database schema right? Are all the processes correctly covered? Do the tasks contain testing scenarios? You should never rely on the AI without proper supervision in place, otherwise you are risking a lot of troubles. In the world of AI agents, a good plan is everything. It can be the difference between a 3-hour coding session and a 9-hour session full of tech debt. And this isn't theoretical. We had two projects running in parallel. On the first one, I had a demo scheduled and wanted the MVP ready. There was no time to review the tasks deeply. The result? I spent the next day fixing issues for several hours. They weren't even bugs, just bad design decisions the agent made because the spec was loose. Since then, I always put the most effort into task definitions. It leads to minimum problems after implementation. ## Coding Ok, so we have the tasks. Now what? Our coding agents take over. We've built an ecosystem of agents in Coder (if you want to know more about our setup, feel free to ping me on LinkedIn) that handle the heavy lifting. Tasks are implemented sequentially, one after another. We learned our lesson here — parallel tasks weren't worth it unless they're truly independent with zero interaction — which is rarely the case. Every task is then reviewed by a review agent, feedback is implemented, and a pull request is created. ## Review by humans That's it, pull requests are created, code is written, feature is implemented. Now it's time for proper human review. We need to be sure the system is secure and everything is implemented as intended. The good thing is, this is done at scale. I wake up in the morning and there are 20 open PRs waiting for me. *"AI writes fast, but accountability is still ours."* The truth is that while the quality of AI-generated code keeps improving, it's not flawless. Every pull request still needs human eyes. Someone who checks whether the code is secure, maintainable, and does what it's supposed to do. I have one golden rule we apply across the team: never ship something where you don't understand every single line of code. If you can't explain why it's there, it doesn't go to production. AI writes fast, but accountability is still ours. ## From MVP to perfection Once everything is implemented, we show the MVP to the client. And here's where the new workflow really compounds: because change requests are cheap now, we can iterate. In the past, reworking the codebase after the first demo could take weeks, so we tried to lock down as much as possible upfront. Now it's often more economical to ship a rough MVP fast and shape the details together with the client, round after round. Same budget, more iterations. Or same number of iterations, faster delivery. Either way, the product that lands at the end is much closer to what the client actually wanted because they helped shape it, not just spec it. This is where we loop back to "Brainstorm again." The cycle can repeat several times before the product is right. ## So what does it mean for clients? 1. **Senior thinking, not senior typing.** The same engineer who designs your system spends more time understanding your business and less time typing what's already been figured out. That mix shifted in your favor. 1. **More iterations for the same budget.** Cheaper implementation means we can afford to try the second and third version of an idea before you sign off. The final product ends up closer to what you actually need, not what we agreed on in the first meeting. 1. **Faster from idea to working software.** What used to take months now takes weeks. That changes what's worth attempting. Experiments that weren't economical two years ago are routine now. 1. **Proof, not promises.** On a recent healthcare project, we spent three hours with the client defining the data model — constraints, edge cases, the messy parts. Claude Code wrote the implementation in 30 minutes. The thinking is where your money goes; the typing is nearly free. *A quick note before I close this off: it sounds like AI solves everything. It doesn't. We'll cover where it works and where it breaks in a separate article.* So yes, I uninstalled my code editor. The typing is nearly free now. The part that needs me is the conversation with you. That's where I'll be. --- ## When Everyone Can Code, What Do You Pay For? URL: https://meetbrackets.com/thinking/when-everyone-can-code-what-do-you-pay-for Author: Pavol Perdík (https://meetbrackets.com/author/pavol-perdik) Published: Apr 30, 2025 Topic: Strategy Read time: 5 min > AI made code cheap. But the code was never where the value lived. Here's what actually matters when the typing is automated. At a dinner a few weeks ago, someone asked me, half-joking: *"So what are you actually selling now that AI can write code?"* I laughed. Then I drove home and thought about it for a week. The question deserves a real answer, because it's the question every CFO is quietly asking about every software vendor right now, and the honest version of the answer is more interesting than the defensive one. So here it is. ## "Code is cheap" It helps to start by noticing that the word *cheap* has two meanings. Cheap means accessible. Democratization of software. Naturally you want the cheapest version of any product or service. Software is no exception. AI made code cheaper. Good for everyone. (Yes, I run a software studio. Yes, I am aware of how this sentence sounds. Bear with me.) But *cheap* also means low-value. And that's the meaning the industry kept tripping over. The code itself was never where the value lived. It was always the thinking the engineers had when they wrote it. Architecture. Data modeling. Failure handling. Every little trade-off they made. Which things to build. Which things not to build. The code was the receipt. The thinking was the work. ## The shape inverted We took an honest look at our delivery process and noticed the whole shape of it had inverted. A six-month project used to be roughly 60–70% development. Writing the code itself. The other 30–40% was architecture, analysis, specification, design. And meetings. Real work, but often invisible to the client. The code was the deliverable. The rest was the *cost* of producing that deliverable. Now it's flipped. On AI-heavy projects (not every project is equally suitable), development is closer to 30% of the time. Agentic. AI writes most of the code. The other 70% is the thinking. And the thinking has stopped being invisible. The work that used to live behind the curtain is now the visible work. Typing got automated. Judgment, taste, and experience got promoted. Consulting in its purest form. Last quarter we built a data management system for a healthcare client. An internal system, where you don't need to follow the design system and branding — ideal for an AI-heavy approach. The traditional timeline would be two months. We delivered it in three weeks. AI did most of the typing, our solution architect did all of the thinking. ## So what does that look like in practice Yes, AI changed how we work. We still build software. Just very, very differently. But here's the thing about software: the rules didn't change. You still need the same processes. User stories. Code reviews. Testing. Security. AI will tell you everything you want to hear. "Wonderful idea." "Brilliant approach." "Such a smart way to frame the problem." It's the most agreeable colleague you've ever had, which is exactly what you want when you're brainstorming at 11pm and need the spark. But it's also exactly what you don't want when you're about to spend three months and €100k on a digital platform. At that point you need someone who'll challenge the brief. Ask the question you forgot to ask. Point at the thing you skipped because it felt obvious. Explain why the obvious answer is wrong for your stage, your team, your customer. Someone who can turn a half-written doc into something concrete enough to actually build, and who'll occasionally tell you to put the doc away for a while. ## Humans love humans AI works with limited context. It cannot produce a system that fits your team, your budget, your stage, your regulator, and your three-year roadmap. It hasn't been in the meeting. It hasn't met your CFO. It doesn't know your last vendor burned you on a multi-tenant decision (real story). We have. We sit in the meeting. We listen. We push back on the brief. We take the risk. Human judgment is what closes the gap between what AI knows and what your situation actually needs. Humans love humans. Even when we don't admit it, we want to talk to real people. Clients are no different. They want a person who reads the room, sees their face when an idea isn't landing, whose judgment they can rely on. I know what you're thinking. *"I'm an introvert. I'd rather click a button than talk to anyone."* Same. Me too. And yet, when production goes down at 4pm on a Friday, nobody wants to chat with a perfectly-trained LLM. You want a human voice. Even if it has bad news. Especially if it has bad news. ![Cartoon of a frustrated developer slamming his desk at 4:05 PM yelling about broken production while an AI chatbot on the laptop calmly apologizes](unnamed.png) We sit in the meeting. Share our experience (so you don't need to repeat the same mistake we saw before). And we would definitely answer the call if something is broken (pretending it almost never happens). ## What I told the friend, eventually So that's what I told him at dinner. The work didn't disappear. It got promoted. The part of our job that used to live in the background, the thinking part, the part nobody invoiced for separately, is now the most important part when the typing is automated. Code is easy. Thinking isn't. And that's what we sell. --- # Glossary ## Dependency Risk URL: https://meetbrackets.com/audit-your-vibe-coded-software/dependency-risk Topic: Audit Your Vibe-Coded Software > Dependency risk is the exposure a product carries through the third-party packages it is built on: unmaintained libraries, known vulnerabilities, licences nobody reviewed, and versions nobody chose deliberately. Code generated with AI tends to reach for a package rather than write the few lines itself, so the surface grows faster than anyone tracks. Every product stands on code somebody else wrote. That is normal and usually sensible. Dependency risk is what happens when nobody can say why a particular package is there, who maintains it, or what would break if it disappeared. ## Where the packages come from A generated solution reflects the patterns that were most common in its training data, which means it reaches for well-known libraries by default. Each suggestion looks reasonable on its own. Across a few months of fast building, the effect compounds: several packages that solve the same problem, transitive dependencies nobody reviewed, and versions pinned at whatever was current on the day the file was written. Nothing about this is visible while the product works. It becomes visible when a library stops being maintained, when a vulnerability is published, or when an upgrade somewhere else in the tree forces a version bump that the rest of the code was never tested against. ## What an audit looks for The dependency tree is one of the few parts of a codebase that can be assessed quickly and objectively. An audit checks which packages are actually imported and which are dead weight, which ones are unmaintained or already carry published vulnerabilities, whether licences are compatible with how the product is sold, and where the same capability was solved twice by two different libraries. It also checks how far the code is coupled to each package. A library used behind a thin internal interface is a decision that can be reversed. A library whose types and idioms spread through the whole product is closer to an architectural commitment, and replacing it later is the kind of work that shows up in [what a code migration actually costs](/thinking/legacy-code-migration-cost). ## Keeping the surface small The point of the exercise is not to remove dependencies for its own sake. It is to know what you rely on, keep that list as short as it can reasonably be, and make sure the pieces you cannot easily replace are the ones you chose on purpose. Read together with [test coverage](/audit-your-vibe-coded-software/test-coverage), it gives a realistic picture of how safely the product can be changed, which is what an audit of [vibe-coded software](/audit-your-vibe-coded-software) is for. --- ## Test Coverage URL: https://meetbrackets.com/audit-your-vibe-coded-software/test-coverage Topic: Audit Your Vibe-Coded Software > Test coverage is the share of a codebase that automated tests actually exercise. In software generated with AI the figure can be misleading, because the tests are usually produced alongside the code they check. They run, they pass, and they can still assert almost nothing about the behaviour the product depends on. Coverage is the easiest quality signal to measure and the easiest one to misread. It answers a narrow question: when the test suite runs, which lines and branches of the code get executed. It does not answer whether anything meaningful was checked while they ran. ## Why the number misleads in generated code When a person writes a test, they usually start from an expectation: this input should produce that result, this permission should be refused. When code and tests are generated together in the same pass, the expectation can be derived from the implementation instead of from the requirement. The test then describes what the code already does, including the parts that are wrong. The result is a suite that executes a large share of the codebase and asserts very little of consequence. Assertions check that a function returned something rather than that it returned the right thing. Error branches are called but their behaviour is never verified. Coverage climbs while the safety it implies does not exist. ## What an audit checks instead Reading the suite is more informative than reading the percentage. The questions are simple: which assertions would actually fail if the behaviour changed, are the paths that handle money, permissions and personal data covered by anything specific, and do the tests still pass when a deliberate fault is introduced. That last check is the fastest way to tell a real suite from a decorative one. It also shows which parts of the product can be changed safely, which is the practical output of a code audit: knowing where you can move quickly and where you cannot. ## Coverage as a starting point Low coverage in a young product is normal and rarely the biggest risk. Untrustworthy coverage is worse than none, because teams act on it. The realistic goal is not a higher percentage but a small set of tests that genuinely protect the behaviour the business depends on, and an honest picture of everything else. The same discipline applies to [dependency risk](/audit-your-vibe-coded-software/dependency-risk), where the surface is also larger than it looks, and it is a large part of what separates [vibe coding from agentic engineering](/thinking/vibe-coding-vs-agentic-engineering-what-actually-changes-when-you-ship). --- ## Technical Debt URL: https://meetbrackets.com/legacy-codebase/technical-debt Topic: Legacy Codebase Audit > Technical debt is the accumulated cost of past shortcuts in a codebase: quick fixes, outdated dependencies, and design decisions that made sense once but now slow every change. Like financial debt, it compounds. In a legacy system that debt is usually undocumented, so the first job of an audit is to make it visible and put a price on it. Every codebase carries some technical debt. It is not a sign of a bad team; it is the natural by-product of shipping under real constraints. In a legacy system the problem is not that the debt exists, but that it is invisible: nobody tracked it, nobody priced it, and it has quietly taxed every release for years. ## Why legacy debt is so hard to see Debt builds up the same way in almost every product. A deadline forces a workaround that never gets revisited. A dependency falls behind because upgrading feels risky. The original developers leave, and with them goes the context that explained why the code looks the way it does. In a legacy codebase those small decisions have had years to compound. The interest gets paid in places that are hard to attribute: slower onboarding, fragile deployments, and estimates that keep growing for no obvious reason. By the time a team asks for an audit, the debt is real but nobody can point to where it lives. ## What an audit actually measures A legacy codebase audit exists to turn that fog into a map. It separates the code that is safe to build on from the code that needs repair first, and it prices the repair so it becomes a decision rather than a fear. That means reading the dependency graph, the test coverage, the hotspots that change most often, and the parts everyone is afraid to touch. AI-assisted analysis has reshaped the economics of this work. Mapping the debt no longer takes weeks of manual archaeology, which is a large part of [what legacy code migration actually costs](/thinking/legacy-code-migration-cost). The faster you can price the debt, the sooner refactoring becomes a plan instead of a gamble. ## From debt to a refactoring plan Naming the debt is only useful if it changes what you do next. A good audit ends with a prioritised list: what to fix before it breaks, what to leave alone because it is stable, and what to rewrite because the cost of keeping it exceeds the cost of replacing it. That ordering is the difference between a rewrite that pays for itself and one that stalls halfway. --- ## Technical Debt URL: https://meetbrackets.com/saas-replacement/technical-debt Topic: SaaS Replacement > Technical debt is the accumulated cost of past shortcuts in the way your software is built and connected. In a SaaS-replacement decision it is not only the debt inside a tool you might build, but the debt baked into how you currently use a vendor: brittle exports, undocumented integrations, and workflows glued together over years. Both sides carry debt, and pricing it honestly is what makes the decision real. When a team decides whether to keep paying for a SaaS tool or replace it with software it owns, the conversation usually starts with licence fees. The number that actually decides it is harder to see: the technical debt on both sides of the choice. ## Debt lives in how you use the tool, not just the tool Every SaaS product you rely on has grown a layer of your own making around it. Data lives in its schema. Integrations pipe information in and out. Reports, automations, and team habits are all built on the assumption that the tool stays exactly where it is. That layer is technical debt too. It rarely appears on any invoice, but it is the reason leaving a vendor feels impossible even when the product no longer fits. The debt is not in the contract; it is in the brittle export, the integration nobody documented, and the workflow that only one person fully understands. ## Build-versus-buy is really a debt comparison Replacing a tool means paying down one kind of debt while taking on another. The software you build starts clean, but it will accumulate its own shortcuts the moment it ships under real deadlines. The honest question is not "which option has no debt" but "which debt do we want to own". BRACKETS frames that as a comparison, not a pitch. Staying means continuing to service the switching cost and the vendor's roadmap. Building means owning the debt yourself, on your own timeline, with the freedom to pay it down when it makes sense. Neither is free; one is under your control. ## Pricing the debt before you commit The way to make the decision real is to price both sides before you commit to either. What does it cost to extract your data and rebuild the integrations you depend on? What does it cost to build and then maintain the replacement? As building custom software gets cheaper, the extraction cost is increasingly the larger number, and that is exactly the debt teams underestimate. Turning "we should replace this" into a plan you can schedule starts with naming that cost out loud. ---