# Koombea AI — full text > Koombea AI Pods ship production software against a committed scope, priced in story points. Building digital products since 2007. Generated 2026-10-20. Blog and press archives are excluded here for length; each post is available as Markdown at its own URL plus `index.md`. Index: https://www.koombea.com/llms.txt ========================================================================== # Purgo AI > A proof of concept for AI-generated data pipelines built out into a production SaaS platform, with Jira and GitHub integration and QA gates. Source: https://www.koombea.com/work/purgo-ai/ --- Purgo's AI agents could write production-grade data pipelines. What they had no way to do was reach a user. We built the platform around them. ## The problem Purgo began as an acquisition: a solution with the foundations for analyzing code with AI, and a CEO, Sang Kim, who could see a larger product in it. The ambition was multi-agent AI doing the work data engineers do by hand, and the target was one of the least forgiving spaces in the field, where output that is merely plausible is worse than no output at all. The intended experience was specific. A user writes a requirement in Jira. What comes back is production-ready code that respects business logic, enterprise rules, and QA standards. The gap was not the intelligence. It was everything around it. The original infrastructure had been built to prove a concept, not to carry a SaaS product, and an engine with no console, no integrations, no QA pipeline, and no interface is not something a customer can buy. ## What we built The product experience, and the plumbing underneath it. A web application, a console, and a dashboard for the AI's functionality to surface through. A Jira integration so a development task could be submitted and its generated code returned against that case. A GitHub integration so outputs are documented and stored automatically rather than by hand. Then the part that decides whether an AI product is trusted twice: a QA and testing pipeline that validates not only the interface but the behavior of the intelligent workflows themselves. An AI feature without a way to check its output is a hope, not a feature. We also carried the documentation, the UI/UX work, and the marketing site materials, so the launch was a product launch rather than a demo with a landing page. - Web application, console, and dashboard - Jira integration for task submission and code retrieval - GitHub integration for automatic documentation and storage - QA and testing pipelines covering the intelligent workflows, not just the UI - Documentation, UI/UX, and launch materials ## How it works The requirement goes into Jira: A user writes a ticket in the tool their team already runs on. No new workflow to adopt. (Where the work already lives) The platform picks it up: The console and dashboard hand the request to Purgo's AI agents with the project's context attached. (Console and dashboard) Agents generate the code: Production-ready pipeline code, written against business logic, enterprise rules, and QA standards. (Minutes, not days) QA validates, GitHub records: The output runs through the testing pipeline, then lands documented and stored in the repository. (Automatic, not manual) Reviewed and deployed: A human reviews code that arrives standardized, maintainable, and readable enough to debug. (The engineer still decides) "From design to console and testing the overall system, Koombea has helped with almost every aspect of getting the platform off the ground." Sang Kim, CEO, Purgo AI ## What happened The source case study publishes no revenue or company-size figures. The one number Purgo does publish is the one that matters to their buyer. - Pipeline creation cut from over 10 days to under 15 minutes, Purgo's published figure - Requirements entered in Jira return production-ready code - Validation, documentation, and deployment run without manual bottlenecks - Output that is standardized and maintainable, and therefore easier to debug than hand-rolled equivalents ## Delivery notes Stack: Python, web application and console, Jira API, GitHub API, QA and testing pipelines. The engagement ran across time zones against a distributed architecture, with backend systems and data flows aligned between teams. Sang singled out onboarding: as the team scaled and changed, new people arrived productive, which is a documentation and process outcome rather than a staffing one. Capabilities applied: Product Engineering, Integrations and Data. Delivered as a committed scope, estimated in story points and priced before work began. ========================================================================== # About Koombea > Koombea was founded in Barranquilla in 2007 and has put more than 200 apps in market. We sell delivered scope priced in story points, not hours. Source: https://www.koombea.com/company/about/ --- Koombea was founded in Barranquilla, Colombia in 2007 and has put more than 200 apps in market since. Today the work ships through AI Pods: a scope you approve in story points, delivered in two-week cycles, at a price that does not move if we sized it wrong. ## Why the company is built this way We billed for time for most of the company's history, which means we know the arithmetic from the inside. When a vendor invoices hours, a project that runs long is not a bad outcome for the vendor. Nobody has to behave badly for that to hurt you. The incentive is in the contract before anyone shows up. So we took the meter out. A story point is delivered, tested functionality. We size the work, you approve the size, and the price holds even when the estimate turns out to be wrong. That commitment is only survivable because AI-First delivery cut the cost of being wrong far enough that we can carry it instead of you. ## Origins Koombea was founded in 2007 in the tropical city of Barranquilla, Colombia. Today we work from Barranquilla and from Naples, Florida, with a remote-ready team spread across many other places. Our name comes from a Colombian dance, the Cumbia, where participants move in short sprints, just like in a typical Agile app development project. The mark in our logo is the sombrero vueltiao. Neither is decoration. ### Where we work - Barranquilla, Colombia: The delivery center, and where the company started - Naples, Florida: 3811 Airport Road N, Suite 100A ## What you can check yourself More than 200 apps in market since 2007. Google, Motorola Solutions, Facebook, and Skype have acquired some of them. Our software design and development unit holds a CMMI-DEV/3 appraisal, which is an outside assessment of how we run delivery rather than a description we wrote ourselves. Client reviews sit on Clutch, where we did not choose the questions. The numbers our clients published are the ones worth reading. Paymentez went from 4,000 daily transactions to 120,000, and from 85 resellers to 4,700 in a year. Do It Center cut bounce rate by 90% and reached an NPS of 70. Each figure came from the client first, and each one sits on a case study you can open. - Building digital products since 2007 - CMMI-DEV/3 appraised software design and development unit - AWS Partner Network, Stripe Verified Partner, Shopify Plus Partner - ISTQB, Certified Agile Tester and Scrum Alliance credentials on staff ## What clients say on Clutch Clutch interviews our clients directly and publishes what they say. These are the numbers as they stand today. We did not choose the questions, and we do not curate the answers. Overall rating on Clutch: 4.9 out of 5. Across 24 verified reviews - Quality: 4.9 out of 5 - Schedule: 4.8 out of 5 - Cost: 4.7 out of 5 - Willing to Refer: 5.0 out of 5 ## Our Koombea values - **Passion**: We read the product, not just the ticket. If a spec would ship something that does not work for your user, you hear it before anyone builds it. That is while the change is still cheap, not at the review. - **Innovation**: AI-First is a working method here, not a label. AI runs across scoping, design, engineering, QA, and deployment. That is the only reason we can fix a price before we know how hard the work turns out to be. - **Respect**: We say when we are the wrong answer. If you have an engineering team and a backlog you own, hourly Staff Augmentation fits better than a Pod. You hear that on the first call, not after the contract. - **Discipline**: Every commitment has a mechanism behind it. We fix scope in points before work starts, and a capacity report goes out weekly. If something slips, you get it in writing that week rather than at the end of a phase. ## How the work is set up One delivery center in Barranquilla, on Colombia hours, with no daylight saving shift. That puts our working day inside the US Eastern business day all year. Same clock as New York in winter, an hour behind it from March to November. One named Delivery Manager owns your priorities and communication, and escalation runs to a named engineering lead and then to leadership. The route is short because the company is not large enough for it to be otherwise. ### What that means in practice - Inside the US Eastern business day: Year round, differing by at most one hour seasonally - One point of contact: A named Delivery Manager, not a shared queue - Response targets agreed before launch: Four severities in writing, and we answer a P1 within two business hours - Your IP, on payment: You own the code, the designs and the documentation ## Our leadership The people below run delivery, engineering, design, quality, and operations. Your Delivery Manager reports into this group, and an escalation that gets past them stops here rather than in a queue. ## Explore our blog Our team writes about what we learn building products. The archive goes back years. ## Partnerships and certifications "We billed for hours for most of this company's history, and the uncomfortable part of that model is that a project going badly is not a bad quarter for the vendor. Story points were the only way I found to put our margin on the same side of the table as your launch date." Jonathan Tarud, Founder and CEO, Koombea ========================================================================== # Product Engineering > New product builds across web and mobile, delivered by an AI Pod against a committed scope, starting with a complete end-to-end loop. Source: https://www.koombea.com/capabilities/product-engineering/ --- Most first phases deliver scaffolding and call it progress. Ours delivers a complete end-to-end product loop you can put in front of a real user. ## The problem Product engineering services are the largest thing a Pod does: taking a product from an idea or a prototype to something running in production with real users on it. Web, mobile, or both, on whatever stack the problem actually calls for. The part that matters is sequencing. We insist that Phase 1 is a complete loop, meaning a user can get in, do the core thing the product exists for, and get a result. Not a login screen, a design system, and a promise. That constraint is unpopular in planning meetings, and it is the single biggest reason projects here do not quietly die in month four. A loop can be tested, demoed, and funded. Scaffolding can only be described. - Phase 1 is a usable end-to-end product, never a stub - Native and cross-platform mobile, decided by the requirement rather than by preference - Web applications, APIs, and the infrastructure to run them - Estimated in story points and priced before work begins ## What this covers - **Mobile products**: Native iOS and Android where the experience demands it, cross-platform where it does not. - **Web applications**: Long-lived systems with real users, real data, and real uptime expectations. - **MVPs that survive**: A first version scoped to prove the thing, not to impress a slide. - **Performance under load**: Built to hold up at the volume you expect, verified before launch. - **Secure by default**: Authentication, authorization, and data protection as part of the build. - **Analytics from day one**: You cannot iterate on a product you cannot measure. ## Native or cross-platform. The requirement decides. This is the first real fork in a mobile build, and it is usually settled by preference rather than by evidence. Here is how we settle it. | | Cross-platform | Native | |---|---|---| | Choose it when | The product is forms, lists, content and standard navigation, and it needs to exist on both platforms at once | The experience is the product, or you depend on hardware and OS features that move fast | | Point cost | One codebase, so roughly one build plus platform-specific polish | Two codebases for shared scope, priced accordingly | | Hardware access | Fine for camera, location, push and biometrics | Required for Bluetooth, NFC, payment terminals, background behavior and deep OS integration | | Design latitude | Good, until you want motion and gesture work that fights the framework | Total | | Where it fails | A team picks it for cost and then specifies a native-feeling product | A team pays twice for a product where nobody could tell the difference | | Our default | Where the requirement genuinely allows it, because the saving is real | Where the requirement demands it, and we will say so plainly | ## What drives the estimate We cannot price a paragraph, but we can tell you exactly what moves the number, because a story point is sized on functional surface area, integration count, and the test coverage needed to ship it with confidence. So the things that make a product expensive are rarely the things clients expect. Screen count matters much less than the number of distinct states each screen has. One more third-party system to reconcile against costs more than several more list views. And a role model with four permission levels is a different product from the same features with one. We would rather show you these levers during scoping than discover them in month three. It is also why Phase 1 is scoped as a complete loop: a loop is the smallest thing whose real cost we can prove. - Distinct states per surface, not screen count: empty, loading, partial, error, offline, permission-denied - Integration count and how badly each partner system behaves under failure - Roles and permissions, which multiply test surface faster than features do - Regulated data in scope, which raises the coverage bar rather than the feature count - Offline or real-time requirements, which change the architecture rather than adding to it ## What this looks like in your industry The engineering is the same discipline. What changes is which failure mode is unacceptable, and that changes what we build first. - Health Services: Clinical workflow, HIPAA-ready handling, and audit trails built as you go rather than reconstructed. - Payments and Lending: Idempotency and reconciliation from the first commit, because a double-post is not a bug you patch later. - Industrial and Field Service: Offline-first as an architecture, not a cache. Crews work where connectivity does not. - Retail and Commerce: Native storefronts and commerce platforms, including StorefrontOS as a starting point. - Technology and SaaS: Multi-tenant isolation and platform APIs other people build against. ## Questions worth asking ### Can you work on our existing codebase rather than starting fresh? Yes, and most engagements are this rather than greenfield. We start with a paid discovery pass to inventory what is there, because estimating work on a codebase we have not read is guesswork dressed up as a number. That pass produces the work breakdown the build is priced from. ### Who decides the stack? We propose it and you approve it, and we record the reasoning so the decision can be revisited rather than re-argued. It is chosen from the requirement, not from what we most enjoy writing. ### What if Phase 1 proves the idea does not work? Then it did its job, and it cost you one phase instead of a year. That is the entire argument for insisting Phase 1 is a working loop rather than a foundation. Scaffolding cannot fail informatively. ### Do we get the code as we go, or at the end? As we go. You have repository access throughout, and formal transfer of source and pipeline access is a gate on Phase 1 acceptance, not a favor at the end. ### Can you take over a project another partner started? Often, and we will tell you honestly when a rewrite is cheaper than a rescue. The discovery pass exists to answer that question before either of us commits to it. ## Products in market, with published results Luna went from nothing to a native app in market in three months. FlightLogger tracks over 1,500 airlines with worldwide coverage of over 30,000 airports. ========================================================================== # Specification Standard > The difference between a story and a specification, the sections a spec needs, and the five-question test that tells you whether an agent can build from it without guessing. Source: https://www.koombea.com/ai-pods/standards/specification/ --- ## A story is not a specification Two kinds of work item arrive on a board. A user story describes what someone wants and why. A technical story describes work whose beneficiary is the system rather than a person: a migration, a performance threshold, a schema change. Both need a spec, and the structure is the same. What differs is the language of the acceptance criteria. Either way, the story captures requirements. It is a starting point. A specification takes those requirements and resolves every ambiguity before work begins. That is the whole distinction, and it is not about section count. A story leaves room for interpretation, and a senior developer fills that room with experience, conversation, and judgment. An agent fills it with a guess. Every gap in the spec becomes a guess in the output. A specification answers every question an implementer would need to build it correctly the first time: - What does done look like? - What happens at the boundaries? - What is explicitly not included? - How will we know it is correct? - What does it connect to? ## The sections a spec needs {#core-sections} Five core sections are always required. For user stories they are written at the business level, client-readable. For technical stories they describe system-level outcomes in plain language, specific and measurable. | Core section | What it contains | Why it is required | | --- | --- | --- | | Goal | One sentence: what this achieves and for whom | Anchors every downstream decision. Without it an agent optimizes for the wrong outcome | | Audience | Who this is for | Shapes scope, language and format | | Acceptance criteria | Numbered, testable statements of done | The agent's definition of done. Each one maps to at least one test | | Out of scope | Explicit exclusions | Prevents over-building. Ambiguity about scope becomes extra features | | Definition of done | An explicit checklist | The agent knows when to stop | ### Context sections, added when relevant {#context-sections} These give the implementing agent the reference material it needs without crowding the core sections. They do not change what the product must do. They define how it connects to everything around it. | Context section | When to include it | | --- | --- | | Design reference | Any work with a visual component. Link the specific frame or node, not the file. Without it the agent reads the wrong frame or guesses | | User flow | Multi-step journeys where the criteria alone do not convey the sequence. Skip it for a single action | | Technical contracts | Whenever the work must satisfy an external interface or constraint. An API specification, a schema, a payload format, a performance threshold. If the contract does not exist yet, implementation is blocked until it does | | Problem | Technical stories where the goal alone does not make clear what exists today and what must change | | Dependencies | When the work cannot start until another item, endpoint or system is ready | | Data sources | Reports, dashboards, and anything consuming external data | **On fragmentation.** Spec information tends to scatter across a tracker, a repository, design files, and a test tool. Each holds a piece and none holds the whole. An agent starts from the work item. If the information is not there or linked from there, the agent does not have it, and fills the gap with its best guess rather than yours. ## Writing acceptance criteria {#acceptance-criteria} Criteria for user stories are business-level. They describe what a person can do and what they experience, not how the system implements it. | Write this | Not this | | --- | --- | | The user can sort the hotel list to show the cheapest options first | Sort returns hotels in ascending order when `sort_by=price_asc` is passed to the API | | Sharing a trip via link lets guests without an account view it | The share token is appended to the URL and validated server-side against a 24-hour expiry | The technical detail is not wrong. It is in the wrong section. Endpoints, parameters and expiry logic belong in the technical contract. Criteria for technical stories are system-level, and still specific and testable. | Write this | Not this | | --- | --- | | The hotel list endpoint responds in under 200ms for payloads up to 100 items under normal load | Performance should be acceptable | | The schema migration completes without data loss on a dataset equivalent to production volume | The migration should work correctly | ## Three tiers, and which work needs which Tiers describe how much ambiguity remains, not which sections exist. They are floors, not targets. | Tier | What it has | Who can build from it | | --- | --- | --- | | Human-workable | Title, description, rough criteria | A senior developer who knows the codebase and can ask questions. Not an agent, and not a developer new to the code | | Agent-assistable | Complete core sections, structured criteria | An agent with human oversight and review | | AI-ready | All of the above plus edge cases, exclusions, definition of done, and every relevant context section | An agent running with minimal oversight. No ambiguity it would have to resolve alone | Not every item needs the top tier. Match it to the risk. | Work type | Minimum tier | | --- | --- | | One-line bug fix, copy change | Human-workable | | Simple interface change, minor feature | Agent-assistable | | New feature, integration, data work | AI-ready | | Auth, permissions, billing, security | AI-ready, no exceptions | The cost of writing an AI-ready spec is an hour. The cost of reworking an ambiguous implementation is a sprint. ## The completeness test {#completeness-test} Before a spec is handed off, five questions. A yes to any one of them is a gap, and the spec goes back. 1. Is there any requirement the agent would have to look up elsewhere to understand? 2. Is there any behavior that is implied but not stated? 3. Could two reasonable people read this and build different things? 4. Are the cases where something should not happen as explicit as the cases where it should? 5. If the agent hits an edge case, is the expected behavior written down? A spec that passes is ready. A spec that does not is a guess factory. ## Who owns what, and when Each artifact has one owner and one moment. The specification is authored and owned by product. Design contributes the design reference when the frame is marked ready. Engineering contributes the technical contract before development begins. Nothing is ready for build until every required section is present and every contributor has signed off on theirs. Quality derives the validation plan from the spec. It is a separate artifact, written from the spec before the build starts rather than after it, and that sequencing is the subject of the [validation standard](https://www.koombea.com/ai-pods/standards/validation/). ## Traceability For the work to be auditable, every feature traces from spec to test. The spec's job is to ensure every acceptance criterion exists before the build starts. The validation plan's job is to map each criterion to a test that proves it. A criterion with no test is not done, and a test with no criterion is not evidence of anything. ========================================================================== # AI Pods > An AI Pod is a lean delivery unit that ships production software against a committed scope, priced in story points, in two-week cycles. Source: https://www.koombea.com/ai-pods/ --- An AI Pod ships production software against a committed scope, priced in story points, in two-week cycles. You approve the estimate before work starts and watch points turn into shipped features every week. ## What you are buying An AI Pod is how Koombea sells custom software development. Most development contracts sell you access to people. You pay for hours, you manage the team, and you carry the risk if the work takes longer than anyone guessed. An AI Pod inverts that. You buy a defined quantity of delivered scope at a price you agree upfront. This works because AI runs across the whole lifecycle rather than sitting beside it as a helper. Scoping, specification, implementation, test generation, and deployment are all AI-First. That compresses delivery enough that we can commit to a price instead of billing you for the discovery. - You approve every estimate before work begins - Weekly reports show points consumed against items shipped - Scope changes go through a formal change order, priced before work starts - Every invoice states the points delivered and the balance remaining ## The two-week cycle Priority Sync: A short call where you say what matters most. The planning that follows is ours to run, not yours to attend. (20 to 30 minutes) Spec: Each item becomes a contract of inputs, outputs, and edge cases, estimated in story points. (Hours, not days) Build and gate: Implementation runs AI-First. Generated tests and automated reviews gate every merge. (Continuous) Ship, review, accept: Reviewed work deploys to production. At the end of the cycle you see it demonstrated and accept it, and the report shows what your points bought. (Every week) ## Two ways to buy capacity ### Fixed-Bid Project — A defined scope, a fixed price. Best when you know what you want built. We break the work into a full Work Breakdown Structure, price it in story points, and deliver in phases. Phase 1 always gives you a complete end-to-end product loop, never a foundation stub. - Full Work Breakdown Structure before you commit - One price for the scope you signed - Phase 1 is usable, not scaffolding ### Monthly Capacity Commitment — Standing capacity, drawn down as you go. Best when the roadmap is still moving. You commit to a monthly point capacity across one or more delivery lanes and re-prioritize the queue in any Priority Sync. Capacity moves up or down as the roadmap does. - Monthly point capacity across your lanes - Re-prioritize at any Priority Sync - Unused points bank for 90 days ## What a point measures A point is our unit of delivered work, estimated on a 1, 2, 3, 5, 8 scale that weighs functional scope, integration complexity and testing needs. The steps are deliberately uneven: an 8 is not eight items of work, it is one item nobody should pretend to have sized precisely. Every estimate is yours to approve before work begins, and every invoice states the points delivered against the balance remaining. Each disc is drawn to the size of its own point value. ## Twelve Pods, already priced Most software work arrives in a shape someone has built before. We scoped the twelve shapes we deliver most often and published the point range for each one, so you can price the work before booking a call. Three of them cost between 15 and 50 points and end in a costed Work Breakdown Structure you own. That is the cheapest way to find out what your real number is. ## When an AI Pod is the wrong answer If you have an internal engineering team, a backlog you already own, and you need capacity rather than an outcome, a Pod is the wrong shape. You want Staff Augmentation, where engineers embed in your team at an agreed hourly rate and you direct the work. ## Questions worth asking ### What exactly is a story point? A point is our unit of delivered work. We estimate it on a 1, 2, 3, 5, 8 scale, weighing functional scope, integration complexity, and testing needs. You approve every estimate before work begins. ### How do you commit to a price without padding it? Scope is decomposed into estimated items before anyone commits, so the price reflects work we have actually sized. AI-First delivery is what makes the margin on that commitment viable. ### What happens if an estimate turns out to be wrong? On a fixed-bid project we absorb it. That is the point of a fixed bid. If you change the scope, that goes through a change request with cost and timeline impact quantified before you approve. ### How do I know the AI did not just generate garbage? Because we assume it might. Every item is specified in writing before anything is built, and the plan that proves it is written before the implementation plan, never after. AI implements against that contract, generated tests and automated reviews gate every merge, and an engineer reviews what passes. Quality is a gate, not a phase. ### Who owns the code? You do. All custom deliverables become your sole property upon full payment, including source code, designs, and documentation. ## Start with where you are today. If a Priority Sync feels premature, take the AI readiness assessment instead. It scores where your business stands on AI and what to do next, with no call attached. ========================================================================== # Product Definition Sprint > A scoped AI Pod that turns a product idea into a Work Breakdown Structure, a spec set and a clickable prototype, priced at 25 to 40 story points. Source: https://www.koombea.com/ai-pods/catalog/product-definition-sprint/ --- A short, fixed engagement that turns a product idea into a Work Breakdown Structure, a spec set, and a clickable prototype. The estimate is the deliverable, and it is yours to keep. ## The problem You want a fixed price. A fixed price requires a scope, and the scope is the thing you do not have yet. Most teams break that standoff by asking three firms for a free estimate and taking the lowest number. The lowest number usually understood the least. A free estimate is worth what it costs. Nobody decomposes a system properly on speculation. What arrives is a guess wrapped in a contingency, and the contingency is what you argue about for a year. This Pod inverts that. You buy the scoping work at a small fixed price. You get a real decomposition instead of a sales artifact. - The estimate is produced by the team that would deliver the work - Every item is sized in story points on the 1, 2, 3, 5, 8 scale - You own the output whether or not you go on to build with us ## What this Pod ships - **Work Breakdown Structure**: Every item of scope, decomposed and estimated in story points, with nothing larger than an 8 left standing. - **Spec set**: Inputs, outputs and edge cases for each item, written as a contract rather than a description. - **Clickable prototype**: The core flows, navigable, so direction is validated before a line of production code exists. - **Costed phase plan**: What Phase 1 contains, what it costs, and what a complete end-to-end product loop looks like. ## How we get to a real number in three weeks Scoping is the part of delivery that AI-First changes most. We estimate with ScopeGen AI, our own scoping tool. It turns a client conversation into an estimated work breakdown, calibrated against what each project actually took to deliver. It is why work that used to take two months of billed discovery now takes under three weeks at a fixed price. This is not a lighter process. It is the same decomposition, run faster. ## What it costs 25 to 40 story points, set by how many distinct user journeys the product carries. We quote it before work starts. It does not move once you approve it. Build with us within 90 days and the Sprint credits in full against the first phase. That window is the same one banked points run on. Do not, and you still leave with a decomposition detailed enough to hand to anyone else. Both outcomes are fine. - Points: 25 to 40, agreed before work begins - Timeline: two to three weeks - Credits in full against Phase 1 if you start within 90 days - You own the WBS, the specs and the prototype on payment ## What we need from you One named decision-maker who can answer questions about the business, and about three hours of their time across the engagement. Access to anyone who owns a system the product has to touch. That is the whole ask. You do not need a written brief. Producing the written brief is what you are buying. ========================================================================== # Health Services Software Development > Custom healthcare software on HIPAA-ready infrastructure: patient apps, clinician tools, EHR integration, delivered against a committed scope. Source: https://www.koombea.com/industries/health-services/ --- A clinical product has to fit how care is actually delivered, and it has to prove its handling of patient data. Both are design problems before they are engineering problems. ## What makes this different Health services products carry two constraints most software does not. The first is that the workflow already exists: clinicians have a way of working, usually under time pressure, and a product that adds steps will be abandoned regardless of how well it is built. The second is evidence. HIPAA is not a feature you add. It is a set of claims about access control, audit trails, encryption, and business associate obligations that you have to be able to demonstrate. That is easier to build in than to retrofit, and considerably cheaper. There is a third constraint that gets missed. A health organization is not one audience. Patients, clinicians, front-desk staff, billers and administrators all touch the same records with different goals and different tolerance for friction. A product built for the average of those five fits none of them. We build patient-facing and clinician-facing products on HIPAA-ready infrastructure, with the compliance evidence produced as the work happens rather than reconstructed before an audit. - HIPAA-ready infrastructure, with access control and audit trails from the start - EHR and practice-management integration, including the reconciliation it needs - Telehealth flows: secure messaging, video consultation, scheduling - One product surface per audience, because patients and clinicians do not want the same thing - Written security attestation on completion ## What we build here Nine things we are asked for repeatedly in this segment. Each one is a build with an integration surface, not a feature toggle. - **Patient-facing products**: Apps that patients will actually use between appointments, not just at them. - **Clinician tools**: Built around an existing workflow rather than replacing it. - **EHR integration**: Practice management and records systems, with drift detection. - **HIPAA evidence**: Controls and documentation produced during the build. - **Remote monitoring**: Wearables and connected devices, sized for rollout volume rather than pilot volume. - **Billing and claims**: Medical billing, payment capture, and the reconciliation behind both. - **Practice operations**: Scheduling, staff management, and the administrative load nobody budgets for. - **Outcome measurement**: Instrumented so clinical and product teams see the same numbers. - **Accessibility**: WCAG conformance, which in health is frequently a procurement gate. ## Proof from this segment Two builds in this segment, and the part of each that is publicly verifiable. - Luna, concept to market: A native app for patients and therapists, with EHR integration and GPS tracking - Therapists working on Luna: Serving tens of thousands of patients - Design Award for the Luna app: Third-party recognition rather than a self-assessment Fashioned Health runs on HIPAA-compliant infrastructure with Stripe handling PCI-compliant payments, and it was built that way from the first commit rather than corrected before launch. Founder Thomas Caraballo's aim was to reduce unequal access to care, which meant clinical information had to be legible to people without clinical training. Luna's problem was different. Outpatient physical therapy was losing people at both ends, with more than 50% of therapists reporting work-related pain and 70% of patients not completing their course of care. The obstacles were logistical rather than clinical, which is why the answer was a phone. ## How a health build runs The sequence matters more here than in most segments, because two of these steps are cheap now and expensive later. Workflow observation: We watch how the work is done before we design anything, including the parts nobody documents: the sticky note on the monitor, the second system somebody keeps open, the step that is skipped when the clinic runs late. That is where adoption is won or lost. (Before anything is priced) Compliance scoping: Which data is protected health information, which vendors touch it, who signs the business associate agreement, and how much of the regulated footprint can be engineered away. Cheapest possible moment to ask. (Same week as discovery) Experience design: Designed against the observed workflow rather than against a category convention. Patients and clinicians get separate surfaces, because a shared one means one of them is using somebody else's product. (Against the observed workflow) Architecture for year two: Scale decisions get made once. Connected devices and monitoring produce data volumes that look trivial at pilot size and structural at rollout, so the shape is chosen before the first patient, not after the thousandth. (Decided once) Build in two-week cycles: Delivered by an AI Pod against a committed scope, with a working end-to-end product loop in the first phase rather than a foundation you cannot demonstrate to a clinical stakeholder. (Delivered by an AI Pod) Quality and evidence: Testing runs through the build rather than at the end of it, and the compliance evidence is produced as the controls are written. Reconstructed evidence is how audits go badly. (Continuous, not a final gate) The build itself is priced in story points before work begins. [See how that works](https://www.koombea.com/ai-pods/how-it-works/). ## Who we build for here ### Digital health startups — Get to market before the window closes. Early-stage health companies are usually racing a funding milestone or a competitor, and the compliance work is the part that gets deferred until it cannot be. We scope it alongside the product so the first enterprise security review does not become a rebuild. Where the idea still needs proving, an MVP with a real clinical loop is a better fundraising asset than a deck. - A usable product loop in phase one, not scaffolding - Compliance scoped with the build, not after it - Wearable and connected-device flows where the product needs them ### Enterprise health organizations — Integration surface is the whole job. Payers, pharmaceutical companies and hospital groups rarely have one system of record. They have several that disagree, plus procurement, security review and accessibility gates the product has to clear before anyone uses it. We inventory what is genuinely load-bearing before quoting, because that inventory is the estimate. - Records, practice management and billing treated as three systems - Accessibility raised in scoping, where it is still cheap - Security questionnaires answered from evidence that already exists ### Practices and providers — Administrative load is the problem to solve. Practices handle a large volume of records with a small margin for administrative overhead. Patient portals move booking, records access and treatment plans off the front desk, and Health Information Exchange standards govern what happens when those records move to another authorized provider. Off-the-shelf gets most practices most of the way. Custom is for the part it does not reach. - Patient portals for booking, records and treatment plans - Records exchange that follows the standard rather than approximating it - Built around the existing practice management system, not against it ### Projects in trouble — Find out whether it can be saved first. A stalled clinical build is usually not stalled for the reason its owner thinks. Before you write off the investment, we run a technical and clinical assessment against the actual failure: adoption, integration drift, performance, or a compliance gap discovered late. Sometimes the answer is a rebuild. Often it is not, and knowing which is worth the assessment on its own. - Assessment before commitment, with an honest verdict - The failure named, rather than the symptom - Existing investment recovered where it can be Product planning sits inside all four rather than beside them. Roadmaps, opportunity analysis and market framing are part of the same engagement, because a health product that is aligned to the technology and not to the operation gets built correctly and used by nobody. ## HIPAA, treated as architecture Modern care runs on stored data. Records, imaging, monitoring streams, and increasingly the analytics built on top of them to improve treatment plans. All of it sits inside the Privacy Rule, the Security Rule and the Breach Notification Rule, and the enforcement is real. The distinction that matters is that HIPAA compliance is an organizational state, not a software property. Your policies, your training and your business associate agreements are part of it, and no development partner can hand you the whole thing. What is ours to do is make the product's handling of protected health information defensible, and produce the evidence behind that. There is also no HIPAA certification scheme. Anyone selling you HIPAA certification is selling something that does not exist. We build the controls, produce the documentation, and provide a written attestation on completion. Your counsel or your auditor owns the sign-off, because a self-assessment is not evidence. In this sector the consequence of getting security wrong is not a fine and an apology. That is why it is scoped first and why we would rather shrink the regulated footprint than defend a larger one. ### What lands on your side - A stated business associate position: Which agreements are required, and who signs them, settled before work starts - An access control and audit trail model: Documented as built, not described after the fact - Encryption in transit and at rest: With the key handling written down - A subprocessor and data residency statement: Every vendor that touches protected health information, named - Written security attestation: Covering the agreed security checks and any known critical or high-severity findings ## Product types we get asked for - Patient care and engagement apps - Telehealth: secure messaging, video consultation, scheduling - Remote patient monitoring and connected-device apps - Reminder, adherence and alerting systems - Patient portals and electronic health record software - Practice management and hospital management systems - Medical billing and claims applications - Staff scheduling and clinical workforce tools - Healthcare CRM and patient relationship systems - Patient data analysis and reporting tools - Clinical decision support and reference tools - Medical information systems and records exchange ## Where health projects usually go wrong Clinical software rarely fails on the build. It fails on adoption, and the causes are consistent enough to design against before a line is written. - The product adds steps to a workflow already running under time pressure, so clinicians route around it and usage data looks like a technical problem - HIPAA is treated as a launch checklist rather than an architecture, so access control and audit trails are retrofitted at several times the cost - EHR integration is scoped as one connection when the records system, the practice management system and the billing system all disagree - One interface is built for patients and clinicians together, so it is tolerable for both and good for neither - Accessibility is discovered during procurement, after the build is complete, because in health it is frequently a purchasing gate rather than a preference - The pilot works and the rollout does not, because monitoring data volume was sized against fifty patients rather than fifty thousand ## How health work is scoped and priced Patient-facing and clinician-facing builds are delivered by AI Pods against a committed scope, estimated in story points and priced before work begins. The estimate is built from the integration surface and the workflow observation, not from a screen count. Compliance work sits outside that. HIPAA attestation and audit support are scoped as a retainer or a fixed fee, because the deliverable is an opinion rather than a feature. When a build and a compliance engagement run together, they are two lines on two bases, and we state them separately. ## Partnerships and certifications Third-party attestations, which are the only kind worth listing. Our development unit is appraised at CMMI-DEV/3. ## Questions worth asking ### What makes an app HIPAA compliant? Not a certificate. HIPAA compliance is a set of demonstrable claims about access control, audit logging, encryption in transit and at rest, and the business associate agreements covering every vendor that touches protected health information. We produce that evidence as the work happens, because reconstructing it before an audit is where the cost lands. ### Can you make us HIPAA compliant? No development partner can, and be sceptical of one that says otherwise. Compliance is an organizational state that includes your policies, your training and your agreements, not just your software. What we can do is make the product's handling of protected health information defensible and hand you the evidence for it. ### Can you integrate with our EHR? Yes, and the honest answer is that the integration is usually more than one system. Records, practice management and billing often hold different versions of the same patient, so the work includes detecting that drift rather than assuming it away. We inventory which systems are actually load-bearing before quoting. ### How long does a telehealth build take? It depends on whether you are building the clinical workflow or wiring existing ones together. Luna reached market in three months as a native app. We scope from the workflow and the integration surface rather than quoting a category average, because those two things account for nearly all the variance. ### Do you handle accessibility? Yes, to WCAG conformance, and we raise it during scoping rather than at launch. In health services accessibility is regularly a procurement requirement, which means discovering it late does not just create rework, it can stall a sale. ### Can you build for wearables and connected devices? Yes, and the interesting part is rarely the device. It is what the stream does to your architecture once the pilot ends. We size that at rollout volume rather than at pilot volume, because that is the number that decides whether the design survives. ### Our project has stalled. Is it worth rescuing? Often, and it is worth finding out before you write off the investment. We assess against the actual failure rather than the symptom, because a clinical build that nobody uses is usually a workflow problem wearing a technical costume. Sometimes the verdict is a rebuild. We will say so if it is. ### Do you work with practices, or only with product companies? Both. The work differs more than the technology does. A practice is usually trying to remove administrative load and move patients onto a portal, and the constraint is the practice management system already in place. A product company is building something to sell, and the constraint is the integration surface of everyone it sells to. ### Who owns the compliance sign-off? You do, and your counsel or auditor does. We build the controls, produce the documentation, and provide a written security attestation on completion. We do not certify ourselves, because a self-assessment is not evidence. ### When should we bring compliance into the conversation? Before the architecture is settled. Retrofitting an audit trail, a retention policy or a data residency constraint into a live clinical system is the single most expensive way to acquire it, and it is the most common reason a health build costs more than it was quoted. ## Explore other industries - Payments and Lending - Industrial and Field Service - Retail and Commerce - Technology ## Where to go next Two builds, and the two capabilities a health product leans on hardest. - Luna: Case study: in-home physical therapy, three months from concept to market - Fashioned Health: Case study: a HIPAA-compliant telehealth product with compliance built in, not retrofitted - Governance, Risk and Compliance: The capability this segment leans on most, ending in a written attestation rather than a certificate that does not exist - Product Design: Where the workflow observation actually happens, before a clinician is asked to change how they work ========================================================================== # Luna > In-home physical therapy taken from concept to market in three months, with EHR integration, practice management and GPS-tracked visits. Source: https://www.koombea.com/work/luna-care/ --- A native app that took in-home physical therapy to market in three months. ## The problem Outpatient physical therapy loses people at both ends. Luna cited more than 50% of therapists suffering work-related pain, and 70% of patients failing to complete their courses of care. The obstacles were logistical rather than clinical: traffic, waitlists, and waiting rooms. Luna's answer was to bring the therapist to the patient, which only works if scheduling, records, and payment all happen on a phone. ## What we built A native mobile app serving both patients and therapists, with electronic health record integration, practice management, real-time chat, a five-star review system, custom availability management, and GPS tracking. The product is the business. As co-founder Ryan Gaffney put it, "Our entire product IS the mobile experience for our users." ## What happened - Launched to market in three months, meeting an aggressive timeline - Serves thousands of therapists and tens of thousands of patients - Early market entry established brand recognition ahead of competitors - Indigo Design Award recognition for the mobile MedTech app ## Delivery notes Stack: Native mobile, healthcare data encryption, EHR integration. Capabilities applied: Product Engineering, Product Design. Delivered as a committed scope, estimated in story points and priced before work began. ========================================================================== # ScopeGen AI > ScopeGen AI turns a client conversation into a structured, estimated work breakdown. It is why we can price a scope before it is built. Source: https://www.koombea.com/products/scopegen-ai/ --- ScopeGen AI converts a discovery conversation into a structured work breakdown with story point estimates against every item. ## Scope your project in about 15 minutes Tell ScopeGen AI what you want to build. It asks the questions a scoping session would ask, then drafts your Project Brief and requirements. No call required to start, and you can close the tab and come back. Start it here: https://www.koombea.com/products/scopegen-ai/#scopegen ## What the conversation turns into Thirty-eight seconds, no sound. You pick a path, answer the questions, and add the detail; the Project Brief and the requirements come out of that. ## The problem it solves Fixed-price software quotes are usually one of two things: a guess with a margin bolted on, or six weeks of unpaid discovery disguised as a sales process. Neither is good for the buyer. The bottleneck is decomposition. Turning "we need a patient portal" into 140 estimable items is slow, and until it is done nobody can price anything honestly. ScopeGen AI compresses that step. It takes the transcript and artefacts from a discovery conversation and produces a draft Work Breakdown Structure: items, acceptance criteria, dependencies, and a story point estimate on each. Our engineers then review and correct it, which is a far shorter task than authoring it. - A draft Work Breakdown Structure from a discovery conversation - Acceptance criteria and dependencies on each item - Story point estimates our engineers review before anything is quoted - The same structure becomes the delivery backlog, so nothing is retyped ## How it works Five steps. The first three happen in the chat above, on your own time. The last two happen with our engineers. Describe the build: Say what you want to build, in plain language. No template to fill in. (Minutes) Answer the questions: ScopeGen AI asks about goals, priorities, users, and constraints. The same ground a scoping session covers. (About 15 minutes) Add the detail: Features, integrations, and anything the build has to talk to. Your Project Brief and requirements are drafted from this. (Same session) Review it with us: Our engineers walk you through the draft, correct the estimates, and add architecture and delivery sequencing. (One call) Sign off a committed scope: You approve a Work Breakdown Structure priced in story points. That document becomes the delivery backlog. (Before any code) What comes out is a document you can circulate. Your team, your board, and whoever has to approve the spend all read the same scope we quoted against. ## What you walk away with The first two come out of the session itself. The rest are added on the review call, because they are judgments about your build rather than restatements of what you told us. - **Project Brief**: Goals, context, and what success has to look like. - **Requirements document**: Prioritized features, user stories, and acceptance criteria. The PRD. - **Expert review**: Our engineers walk the draft with you and correct it. No estimate reaches you unreviewed. - **Architecture outline**: System design, integrations, and the dependencies that drive sequencing. - **Timeline and sequencing**: Phased milestones, and what lands in which two-week cycle. - **Effort and resourcing**: A story point estimate on every item, role-based time ranges, and the team those imply. ## Why start here - **No scope ambiguity**: Requirements written down and agreed before anyone commits. Rework is what ambiguity costs, and it is billed later at full rate. - **Decisions in days**: Planning that conventionally runs to weeks of discovery starts in about fifteen minutes and reaches a reviewed scope in one call. - **One document everyone reads**: Stakeholders, budget holders and engineers work from the same breakdown, so the argument happens over the scope rather than over whose version is current. - **Risk found early**: The hard parts surface during decomposition, while moving them is still free, rather than in the sprint that discovers them. ## What it does not do ScopeGen AI does not send you a quote. It produces effort and resourcing outputs; the dollar figure comes after the review call, from Koombea's pricing model, against the scope the engineers signed off. An unreviewed AI estimate is exactly the kind of thing that makes fixed-price delivery fail. The tool removes the typing, not the judgment. What you sign is one committed scope at one price. That is the thing you can hold us to, and it is the reason the review step is not optional. ========================================================================== # AI Pods Catalog > Twelve scoped AI Pods with a published point range each. Assessment, build, modernization, quality and compliance work you can price before you call. Source: https://www.koombea.com/ai-pods/catalog/ --- Most software work arrives in a shape someone has built before. We scoped the twelve shapes we deliver most often and published what each one costs in story points. ## Why a catalog exists at all Every engagement differs in its details. Almost none differ in shape. A legacy assessment is a legacy assessment. A prototype that needs hardening needs the same set of things every time. So we scoped the twelve shapes we deliver most and published a point range for each. Read a range, run the arithmetic against your budget, and decide whether a call is worth booking. - Ranges vary because scope varies, not because the price is negotiable - Three Pods are small enough to buy as a first step, and each ends in a scoped estimate - Work that is not listed here is still an AI Pod, scoped the same way ## Start: from idea to production For a product that does not exist yet, or exists as something nobody will put in front of a customer. - Product Definition Sprint: You cannot get a fixed price because nobody can describe the thing yet. Ends with a Work Breakdown Structure you own. 25 to 40 points. - Prototype to Production: Someone built it in Cursor, Lovable or v0. It demos beautifully and nobody will ship it. Assessment 15 to 25 points, build from 100. - MVP Launch: You need a complete product loop running in production, not a foundation to keep funding. 200 to 400 points. ## Modernize: systems that work but cost too much For a codebase that still serves customers and still holds revenue, where the price of every change has quietly tripled. - Legacy Assessment: Worth saving, rewriting, or replacing? A costed answer before you commit a budget to the wrong one. 30 to 50 points. - Monolith Decomposition: One codebase where every change is a risk and nobody will touch the oldest parts. 250 to 600 points, phased. - Stack Upgrade: Three major versions behind, and the security patches stopped arriving. Runtime current, architecture untouched. 120 to 300 points. - Data and Integrations: The systems do not talk, so someone re-keys the same record into three tools. 80 to 250 points. ## Ship: a roadmap that keeps moving For a product already in production, where the constraint is throughput rather than a single defined outcome. - Ongoing Delivery: The roadmap moves faster than hiring does. Standing point capacity, re-prioritized every Priority Sync. From 80 points a month. - Design System: Every screen was designed from scratch and it shows. Components, tokens, and the documentation that stops the drift. 60 to 140 points. ## Stabilize: quality you can measure For a product that ships, but ships nervously. - Test Automation: Your regression suite is a person clicking for two days before each release. Converted to gates the pipeline enforces. 80 to 200 points. - Bug Burndown: A P1 and P2 backlog that grows faster than it clears. Triaged, fixed, and gated so it does not refill. 40 to 150 points. ## Govern: the audit that is blocking a deal Priced as a fixed fee rather than in story points, because the deliverable is an opinion rather than a feature. - Compliance Readiness: SOC 2, HIPAA or PCI is now a line item in someone else's procurement checklist. Gap assessment, remediation plan, evidence. Fixed fee. ## Start with the cheapest useful thing Three Pods here cost between 15 and 50 points. The Product Definition Sprint, the Legacy Assessment, and the assessment stage of Prototype to Production. Each is small enough to approve without assembling a committee. Each ends the same way: a scoped, costed Work Breakdown Structure for the larger work behind it. You own that document whether or not you build with us. Buying the estimate first is how you learn the real number without betting the project on it. Start the work it prices within 90 days and the assessment credits in full against the first phase. In the case where you go ahead, finding out what the real number is costs you nothing. The 90 days is the same window banked points run on. ## What is not on this page A catalog covers the common shapes. It does not cover yours if yours is genuinely unusual. Work outside these twelve is scoped exactly the same way. We decompose it into estimated items, price it in story points, and you approve the estimate before anything starts. The catalog is a shortcut, not a boundary. ========================================================================== # Tuily > A Mastercard corporate card and spend platform for Colombian SMEs, built from idea to launch as a Koombea venture and acquired by Bold. Source: https://www.koombea.com/work/tuily/ --- ## Sources Figures on this page are the ones published in Forbes Colombia. ========================================================================== # Staff Augmentation > The second engagement model. Engineers embed in your team at an agreed hourly rate, you own the backlog and direct the work. Source: https://www.koombea.com/staff-augmentation/ --- If you have an engineering team and a backlog you already own, you want capacity you direct. That is Staff Augmentation, billed hourly, and it is a different purchase from an AI Pod. ## When this is the right answer AI Pods suit a defined outcome. Staff Augmentation suits a defined gap. If your team owns the roadmap, runs its own ceremonies, and simply needs more hands inside that process, buying a committed scope would add a layer you do not want. In this model, engineers embed in your team at an agreed hourly rate. You set the priorities, you run the standups, and you carry the delivery risk, because you are the one directing the work. - You own the backlog and direct the work day to day - Billed hourly at an agreed rate, with no committed scope - Engineers work inside your process and your tooling - You carry the delivery risk, because you hold the decisions ## Staff Augmentation or an AI Pod | | Staff Augmentation | AI Pod | |---|---|---| | What you buy | Hours of capacity | Delivered scope, in story points | | Who owns the backlog | You do | We do, against your priorities | | Who directs the work | You do | Your Delivery Manager does | | Who carries delivery risk | You do | We do, on the agreed scope | | Basis of billing | Hourly rate | Price per story point, agreed upfront | | What you get weekly | Whatever your process produces | A capacity report of points consumed against items shipped | | Best when | You need capacity inside a process you run | You need an outcome at a known price | ## What we will not do here We will not dress this model up in the vocabulary of committed delivery. Hourly capacity is not a delivery guarantee, and the difference between the two matters most on the day a date slips. We will also tell you when we think you are buying the wrong model. If the work has a definable outcome, a Pod will almost always cost you less for the same result. ## Questions worth asking ### What is the difference between staff augmentation and outsourcing? Staff augmentation buys capacity. You keep the backlog, run your own ceremonies, and direct the work. The alternative is a committed scope, where we own delivery against a price you agree upfront. Both are on the table here. The choice turns on one question. Do you want to direct the work, or receive a result? ### When is staff augmentation the wrong choice? When you can define the outcome. Paying hourly for work with a definable outcome leaves the schedule risk with you, and you fund the discovery either way. If you can describe what done looks like, an AI Pod costs you less. ### How quickly can engineers start? Two weeks from an agreed rate and scope of involvement. No scoping phase runs first. That is the one speed advantage this model holds over a committed scope. ### Can we move to an AI Pod later? Yes, and teams take this path routinely. They start hourly while the roadmap still moves, then switch to a committed scope once a phase holds still long enough to price. The engagement changes, the people do not. ========================================================================== # Nearshore Software Development > Nearshore delivery from Latin America, sold as committed scope rather than discounted hours. Full timezone overlap, priced in story points before work starts. Source: https://www.koombea.com/nearshore-software-development/ --- The reason to build in Latin America is that the work and the decisions happen in the same working day. If the pitch is a lower hourly rate, you are being sold a discount, not a delivery model. ## What overlap buys you A blocked engineer in a twelve-hour offset costs you a day. The question goes out, the answer arrives tomorrow, and the item that should have taken an afternoon takes a cycle. Repeat that across a backlog and the rate advantage is gone before the quarter ends. Koombea has delivered from Barranquilla, Colombia since 2007, inside US business hours. A question asked at ten is answered at ten. That is the entire mechanism, and it is the only one that survives contact with a real roadmap. We do not sell this as an offshore alternative or a low-cost option. That framing prices delivery against the cheapest hour available and tells you nothing about whether the software ships. - Full overlap with US business hours, not a two-hour window - Decisions and delivery inside the same working day - Delivered from Barranquilla, Colombia since 2007 - CMMI-DEV/3 appraised, which is an independent look at how we deliver ## Nearshore, offshore, and what you are buying | | Typical offshore | Nearshore with AI Pods | |---|---|---| | Timezone overlap | Two hours, if the team shifts | A full working day | | What you buy | Hours at a discounted rate | Delivered scope, in story points | | When the price is known | After the change order | Before work begins | | Cost of a blocked item | A day, waiting for the answer | The length of the conversation | | Who carries delivery risk | You do | We do, on the agreed scope | | What the rate tells you | How cheap the hour is | Nothing. Points are the unit | ## Why we price the scope, not the hour An hourly rate rewards the vendor for taking longer. It is the only pricing model in professional services where the buyer and the seller want different things on every single day of the engagement. AI Pods are priced in story points against a committed scope, agreed before work begins. If an item takes longer than estimated, that is our problem. The rate you would have paid per hour never enters the conversation, which is why we do not publish one. - Scope decomposed and estimated before anything is approved - Nothing larger than an 8 enters the backlog, so no item hides a surprise - Change orders are priced upfront, with no penalty, because changing your mind is product learning - You are never billed per AI call or per seat, and model tokens above a monthly allowance pass through at cost, with no markup, under a model configuration you approve ## When nearshore is the wrong answer If your team owns the roadmap, runs its own ceremonies, and needs hands inside a process you already control, a committed scope adds a layer you do not want. That is Staff Augmentation, and we keep it on the table. If the work is genuinely undefinable, no fixed scope is honest. We would rather run a paid discovery pass and produce something estimable than commit to a number neither of us believes. ## Questions worth asking ### What should you look for in a nearshore software development company? Overlap first, because it decides how fast an engineer gets unstuck. Then ask how the firm prices the work. A discounted hourly rate buys you a rate, not a delivery commitment, and the schedule risk stays with you. Ask who absorbs a bad estimate. ### What is nearshore software development? Building software with a team in a nearby country that shares most of your working day, rather than one twelve hours away. For US companies that usually means Latin America. The defining property is timezone overlap, which is what determines how fast a blocked item unblocks. ### How is nearshore different from offshore? Offshore is normally sold on rate and normally sits outside your working day. Nearshore is sold on overlap. The distinction matters because a rate advantage is spent on waiting, and waiting is invisible in the quote and obvious in the schedule. ### What does nearshore development cost? We do not quote an hourly rate, because we do not sell hours. Work is estimated in story points against a committed scope and priced before it starts, so the number you approve is the number you pay. Capacity tiers and the terms behind them are published on the pricing page rather than kept in the contract. ### Where is your team located? Barranquilla, Colombia is the delivery center and where the company started in 2007. Our US office is in Naples, Florida. ### Do we manage the team day to day? Not on an AI Pod. Your Delivery Manager owns the backlog against your priorities, and you get a capacity report each cycle showing points consumed against items shipped. If you want to direct the work yourself, that is the Staff Augmentation model instead. ## Where to go next - AI Pods: The delivery model - Pricing: Capacity tiers and story points - Staff Augmentation: When you want to direct the work - Barranquilla: The delivery center ========================================================================== # Shopify Plus Agency > A Shopify Plus Partner building commerce platforms, replatforms and the integrations behind them. Scoped in story points and priced before work starts. Source: https://www.koombea.com/shopify-plus-partner/ --- Storefronts are the easy part. What determines whether a Plus migration succeeds is the catalog, the ERP integration, and the order data you have to carry across without losing it. ## What a Plus project consists of Most Shopify Plus work arrives described as a redesign and turns out to be a data project. The theme is a few weeks. The catalog reconciliation, the ERP and OMS integrations, the historical order migration, and the redirect map for a URL structure that changes shape are the rest of it, and they are where a replatform goes wrong. We scope those first. Before anything is committed, we inventory the catalog, the integrations that touch it, and the volume of order history that has to survive the move. That inventory is what the estimate is built from, which is why the price holds. We are a Shopify Plus Partner, which gives Plus-tier access for builds, replatforms and the checkout extensibility work that Plus alone permits. - Catalog and variant reconciliation before the theme is touched - ERP, OMS and 3PL integration with retries that do not double-post - Historical order and customer migration, verified by reconciliation - Redirect maps built from the live URL set, not from the sitemap ## What Plus Partner status means Shopify started the Plus Partner program in 2016. It recognizes agencies with a track record of building on the platform for high-volume merchants, and it is granted by Shopify rather than claimed. Koombea has held the status since 2018. In practice it gets you three things. Plus-tier capabilities that the standard platform does not permit, checkout extensibility included. An escalation path when the constraint turns out to be Shopify rather than the code. And access to the Plus app and partner ecosystem when the right answer is to integrate something rather than build it. ## Where Plus Earns the Upgrade - **Multichannel selling**: One catalog behind online, retail, marketplaces, and social, so stock and price are not reconciled by hand. - **Integration headroom**: Higher API limits and Plus-only endpoints, which is what makes real-time ERP and OMS sync viable at volume. - **Checkout you can change**: Checkout extensibility, which Plus alone permits, for B2B terms, custom validation, and payment routing. - **Wholesale and B2B**: Company accounts, price lists, and approval flows, without a second storefront to maintain. - **Scale and security**: Shopify carries PCI scope and flash-sale traffic, which removes two things you would otherwise own. - **Support with a path**: A named escalation route, so a platform-level blocker does not become a support ticket queue. ## What we build on Plus - **Replatform to Plus**: Magento, WooCommerce and custom carts, moved with the order history intact. - **ERP and OMS integration**: NetSuite, SAP and the middleware between, with idempotent writes. - **Checkout and payments**: Checkout extensibility, Shopify Payments, and third-party processors. - **Headless storefronts**: Hydrogen and custom front ends where the theme layer is the constraint. - **B2B on Plus**: Company accounts, price lists and the approval flows wholesale needs. - **StorefrontOS**: Our commerce foundation, so the common surface is already built. ## Why the replatform estimate usually moves A Plus quote that moves after signature almost always moves for one of four reasons, and all four are discoverable before anyone commits. - The catalog has more real variants than the export suggests, because configurable products expand on migration - An integration nobody listed turns out to be load-bearing, usually tax, shipping or a returns portal - Order history has to move, not just customers, because support needs it and the finance team needs it more - The old URL structure does not map cleanly, so redirects become a project rather than a file ## How this is priced Commerce work is delivered by AI Pods against a committed scope, priced in story points and agreed before work begins. A replatform is estimated from the catalog and integration inventory, not from a page count. Where StorefrontOS covers a surface you need, the point cost drops, because the foundation is already built and tested. ## What you get that a theme shop cannot give you You get a software company that does commerce work, not an agency that only does Shopify. On a replatform that difference shows up in the parts of your project which are not the store: your ERP wiring, your migration reconciliation, and the native app you will want six months later. Your work runs through a CMMI-DEV/3 appraised process, which is an independent appraisal rather than a self-assessment. Products built here have been acquired by Google, Motorola Solutions, Facebook, and Skype. - Your first store, or a multi-region Plus replatform, scoped the same way - Your ERP, CRM, WMS and 3PL integrations, including the middleware between them - Your order and customer history moved, then verified by reconciliation rather than spot check - Your checkout extended where Plus permits it, including B2B terms and payment routing - Your store as a native iOS and Android app, through StorefrontOS - Your brand as a design system, when a purchased theme will not carry it - Your team's hours, in English or Spanish, on Eastern time year round "With Shopify, I'm able to maintain speed while bringing new products or promotions to market, which allows me to stay innovative and at the cutting edge of my industry." Elías Manopla, CIO, Do It Center ## Tell us about the store The store URL and a sentence about what has to change is enough to start. We will come back with how we would scope it and what it would cost. ## Questions worth asking ### How long does a Shopify Plus replatform take? It depends almost entirely on integrations and catalog size, not on design. A single-region store with a clean catalog and two integrations is a materially different project from a multi-region catalog wired into an ERP. We scope both the same way, by inventorying what exists before quoting, so the number you get is built on the actual surface rather than an average. ### Do we lose our SEO when we move to Plus? Only if the redirect work is treated as an afterthought. URL structures change shape on a replatform, and the risk is concentrated in the pages that already rank. We build the redirect map from the live URL set rather than the sitemap, because the sitemap routinely omits URLs that still earn traffic and still carry links. ### Can you work with our existing theme and agency? Yes. A common shape is that a design partner owns the storefront and we own the integration, migration and back-of-house work. We will say so plainly when the split is not worth it, but there is nothing about the model that requires owning the whole project. ### Is Shopify Plus the right platform for us? Not always. Plus is strong when the constraint is commerce operations and weak when the product itself is the differentiator and needs behavior the platform does not permit. We would rather tell you that during scoping than discover it in month four. ### What does the Shopify Plus Partner status get us? Plus-tier access for builds and replatforms, including checkout extensibility, and an escalation path when the constraint is the platform rather than the code. A badge is only worth showing if it gives you something. ## Where to go next - Retail and Commerce - StorefrontOS: The commerce foundation - Do it Center: Case study: online and in-store brought onto one platform - Jamar: Case study: a commerce build for a furniture retailer - Integrations and Data: The capability a replatform leans on most ========================================================================== # Payix > Onboarding a client took months of hand-coded AWS infrastructure. A multi- tenant rebuild turned a new client environment into a configuration step. Source: https://www.koombea.com/work/payix/ --- A payment platform rebuilt so new clients could be provisioned without hand-built infrastructure. ## The problem Payix arrived after their previous development partner's quality and responsiveness declined. The deeper issue was architectural: creating a new client environment took months, because each one had to be hand-coded along with its AWS infrastructure. That put a hard ceiling on revenue. Demand existed, and the platform could not be provisioned fast enough to meet it. ## What we built A multi-tenant payments platform with automated environment provisioning and AWS infrastructure. New client environments can be configured instead of hand-built. We chose the stack against each requirement and automated deployment across client environments. ## What happened Payix published this on the engagement: "The Payix team is very thankful to Koombea for stepping in and helping us move past our previous development partner. With Koombea now by our side, we're achieving our client on-boarding goals and maximizing revenue opportunities." - Client onboarding no longer requires months of hand-built setup - Revenue can start sooner after a client signs - Architecture no longer caps onboarding capacity ## Delivery notes Stack: Full-stack web, AWS infrastructure automation. Capabilities applied: Platform Modernization, Integrations and Data. Delivered as a committed scope, estimated in story points and priced before work began. ========================================================================== # Platform Modernization > Application modernization services for legacy systems that cost too much to change. Incremental cutover, no big-bang rewrite, delivered by an AI Pod. Source: https://www.koombea.com/capabilities/platform-modernization/ --- Legacy system modernization is rarely about technology that stopped functioning. It is about a codebase where every change costs three times what it should. ## The problem The legacy systems that need application modernization are usually not broken. They serve customers, they hold revenue, and they cannot be switched off. What has broken is the economics of changing them: a one-week feature takes six, and nobody can say why with confidence. We do not sell big-bang rewrites. A rewrite replaces a system you understand with one you do not, and it asks you to stop delivering value for a year while it happens. Instead we carve the system into pieces that can move independently, then move them one at a time behind an interface that does not change. That means you get a working system at every step, and you can stop when the economics are good enough rather than when the plan says you are finished. - Incremental cutover, so there is a working system at every step - Zero-downtime database migrations where the business cannot pause - Legacy interfaces preserved until the last consumer has moved - A measured before-and-after on the cost of change, not just on the stack ## What this covers - **Incremental extraction**: Move one bounded piece at a time, behind an unchanged interface. - **Zero-downtime cutover**: Migrations designed so the business never stops taking orders. - **Cost-of-change baseline**: Measure how long a change takes now, so the improvement is a fact. - **Regression safety net**: Tests written against current behavior before anything moves. - **Observability first**: You cannot safely modernize what you cannot see running. - **Dependency exit**: Remove the single-vendor bottlenecks that made you dependent. ## Three ways to modernize, and the one we do not sell. Most modernization arguments are really arguments about which of these you are doing. Naming it first saves months. | | Rehost | Replatform | Incremental extraction | |---|---|---|---| | What happens | Same system, new infrastructure | Same system, managed services underneath it | Carve out one bounded piece at a time behind an unchanged interface | | What it fixes | Hosting cost and hardware risk. Nothing about the code | Operational burden, patching, and some scaling limits | The cost of change itself, which is the thing you actually came here about | | What it risks | Paying cloud rates for an architecture that cannot use them | Real but bounded. Usually the right first move | Requires discipline to avoid becoming a permanent hybrid | | Delivery shape | A short project with a clear end | A phase, measurable against a hosting bill | Continuous, with a working system at every step | | When we recommend it | A datacentre exit with a deadline and no appetite for change | The system is sound and the operational cost is the pain | Every change is expensive and nobody can say why with confidence | We do not sell a rewrite. It replaces a system you understand with one you do not, and asks you to stop delivering value while it happens. ## Before anything moves, we document what is there The most common reason modernization stalls is that nobody left in the building knows what the system does. Not the architecture diagram version. The version where a nightly job nobody owns writes to a column three reports depend on. So we sell the documentation pass as its own small engagement, and it is frequently the first thing we do for a new client. We reverse-engineer from the codebase and the database: system architecture, module and service structure, data models and the business rules hiding in them, the real workflows, and every integration and dependency we can find. AI does the reading and the first-pass drafting, which is what makes it affordable at the scale of a decade-old codebase. Then a person validates all of it. That part is not optional and we will not describe it as optional, because an unvalidated AI-generated description of a system your revenue depends on is a liability rather than a deliverable. You get version-controlled Markdown as the source of truth, diagrams for the concepts that need them, and PDFs for distribution. It is scoped from an inventory of your codebase rather than from a page count, and it is useful on its own even if you never modernize a line. - Reverse-engineered from the code and the schema, not from tribal memory - AI does the reading at scale, a human validates every claim before it ships - Version-controlled Markdown, diagrams, and distributable PDFs - Sized from an inventory of your codebase, after a short paid discovery pass - Useful for knowledge transfer, refactor planning, audit, or an acquisition ## What drives the estimate Modernization is the hardest thing to price sight unseen, and any partner who quotes it from a conversation is quoting a number they intend to revise. We scope a paid discovery pass first, then price the work from what the inventory actually found. What moves the number is rarely the size of the codebase. It is how tangled it is, and specifically how many places share state they should not. - Test coverage you already have, which is the difference between a safety net and a rewrite - How many consumers depend on the interface being preserved, and whether you can enumerate them - Shared mutable state and database coupling between the pieces you want to separate - Whether the business can tolerate any downtime window at all - Undocumented behavior that turns out to be load-bearing, which is why documentation comes first ## Questions worth asking ### What are application modernization services? They cover the work of moving an existing system off constraints it has outgrown, without stopping delivery while it happens. In practice that means extracting pieces that can move independently, cutting them over one at a time, and keeping the old interfaces alive until the last consumer has moved. The alternative most vendors sell is a rewrite, which trades a system you understand for one you do not. ### How do we know it worked? We baseline how long a representative change takes before anything moves, and measure it again after. That is a fact rather than a feeling, and it is the only modernization metric that maps to why you started. ### Can you do this while we keep shipping features? Yes, and that is the point of the incremental approach. What we ask is that you decide how capacity splits between modernization and features, explicitly, in the Priority Sync. Both come out of the same visible capacity, so the trade is on the table rather than hidden. ### Our system runs on something unfashionable. Is that a problem? No. Old is not the same as bad, and a stable system with a boring stack is often the cheapest thing you own. We modernize the parts where the economics are genuinely broken and leave the rest alone. ### What about the database? Usually the hardest part and the last to move. We design migrations to run with zero downtime where the business cannot pause, which means dual writes and a verified cutover rather than a maintenance window and hope. ### Where will it run afterwards? Decided with you and recorded. We commonly land early phases somewhere simple and operationally cheap, then move to AWS where scale or a compliance requirement justifies the extra surface area. We do not default to the most complex option to look serious. ## Onboarding stopped taking months Payix came to us after their previous partner's quality declined, with a platform so rigid that creating a new client environment took months. Onboarding time decreased drastically. ========================================================================== # Engineering Standards > The standards an AI Pod builds against: how specs get written, how validation is designed before the build, and the twelve systems an agent reaches. Source: https://www.koombea.com/ai-pods/standards/ --- ## A project is twelve systems, not one codebase Most diagrams of software delivery draw phases. Phases are not the problem. The problem is that the information an agent needs is scattered across a dozen systems, and an agent is only as useful as the ones it can actually reach. Each system below has a defined access pattern. Retrieval means the agent queries an index rather than reading raw files. Protocol means a structured connection to a service. Filesystem and command line mean direct access. One system is closed entirely. | System | What lives in it | How an agent reaches it | | --- | --- | --- | | Documentation | Project handbook, product vision, technical solution, decisions, and the domain knowledge that explains how the client's business works | Retrieval | | Specification | Specs, acceptance criteria, backlog, prioritization, and delivery state | Command line or protocol | | Design | Wireframes, interfaces, interaction flows, tokens, and component documentation | Protocol or command line | | Development | Source code, configuration, branch rules, and the committed context file every agent reads at the start of a session | Filesystem and command line | | Validation | Test scenarios per acceptance criterion, coverage, and the traceability between them | Filesystem and command line | | Delivery | The pipeline that builds and deploys, and the distribution that ships releases | Command line | | Infrastructure | Environments, infrastructure as code, and the rules that provision and constrain agents | Command line | | Observability | Error tracking, performance, structured logging, health checks, alert routing, and agent telemetry | Command line or protocol | | Communication | Channels, notifications, system events, and scheduling | Protocol or command line | | Governance | AI usage policy, client disclosure, data classification, tool vetting, and the agent identity and permission model | Retrieval and filesystem | | Account | Contracts, budget, delivery metrics, and escalations. Role-gated, not open to the team by default | Retrieval, restricted | | Secrets | API keys, credentials, environment variables, and signing certificates | No access | ### Domain knowledge is the one most often missing If a client's business is specialized, and in health services, payments, or industrial work it always is, an agent without that context produces confident wrong answers. Any document explaining how the business actually works belongs in the documentation system, whoever wrote it. ## The system an agent never reaches Secrets is human-only. Not restricted, not logged, not role-gated. Closed. An agent references a variable name and never sees a value. That rule is the reason the system exists as its own domain rather than as a folder inside infrastructure: its job is to define how credentials are named, where they live, and how they are injected, so that none of them can arrive in a prompt. Access patterns are easy to write down and easy to quietly widen. This is the one that never widens. ## What the standards cover Six standards cover the twelve systems. | Standard | Covers | | --- | --- | | Specification | What gets built, and how completely it is described before it is built | | Validation | What proves the build matches the spec, designed before the build starts | | Delivery | The quality gates a change passes before it reaches production | | Development | The build loop, and what belongs in the repository before an agent works in it | | Observability | The layers that turn a silent runtime failure into a signal | | Design | How design decisions survive the trip into code | ## Where you stand Knowing the standards is not the same as knowing your own position against them. The [AI readiness audit](https://www.koombea.com/ai-pods/ai-readiness-audit/) scores four dimensions on evidence, tags every finding by how strongly it is supported, and returns a ranked gap list. It is the same procedure we run on our own projects. ========================================================================== # Validation Standard > When one pass writes the code and the tests, a misread spec produces a wrong build that its own tests confirm. This is the mechanism that catches it. Source: https://www.koombea.com/ai-pods/standards/validation/ --- ## The failure mode, stated plainly In traditional development, a developer who misunderstood a requirement usually catches it. Conversation, code review, or QA surfaces the gap. With an agent the failure looks different. A developer prompts for an implementation. The agent generates the code and the tests from the same reading of the spec. The developer ships it. The implementation is wrong, the tests pass, and the misreading never surfaces. This is not a defect in the model. It is a structural property of any system that generates both the artifact and the check in one pass. It is the specific thing this standard exists to prevent: **code that passes its own tests because the same misunderstanding generated both.** Accountability does not move. The agent is the tool, not the deliverer. The person who signed off is answerable for what shipped. ## Two kinds of validation **Product validation** proves the build matches the spec. **System validation** proves the agent behaved correctly, that it interpreted the spec as intended, did not drift, and produced auditable behavior. A project needs both. Validation is not a safety net for AI mistakes. It is the mechanism that makes AI-First delivery auditable at all. There is a longer arc here. As this way of working matures, the work shifts from writing code, to reviewing generated code, to designing the systems in which agents write and review code. At each step the person moves further from the artifact and catches less by intuition. The validation system has to cover that growing distance. ## The behavior contract Quality designs what must be proven. Engineering decides where each scenario physically lives. That split is deliberate, and it is the opposite of the traditional bottleneck. Generating a test at any layer is now cheap. The old constraint, that there was never time to automate, has collapsed. What is left, and what does not automate, is deciding what to prove and where an agent is likely to diverge from the spec. Every scenario in the plan carries four tags. | Tag | Values | What it answers | | --- | --- | --- | | Section | Happy path, validation rules, edge cases, accessibility | What kind of behavior this covers | | Run purpose | Smoke, functional, regression, usability | When it runs, and in which pipeline | | Severity | Critical, high, medium, low | What to fix first when it fails | | Compliance risk | An optional note per scenario | Where an agent could plausibly diverge from the spec | Run purpose describes when a scenario runs, not how it is built. A scenario can carry more than one. The point is to enable subset runs. Severity is independent of the other two. A happy-path scenario can be critical if it is the purchase flow, or medium if it renders an avatar. An edge case can be high if it loses data silently, or low if it is cosmetic. ### The compliance risk note is the sharp part It is required wherever an agent is plausibly likely to ship something that passes the literal scenario and violates the spec's intent. It names the specific wrong implementation the agent might choose. A real one: if the spec says the list endpoint returns items already sorted by the backend, an agent may sort the response correctly and still render it in insertion order. So the scenario asserts the visible order, not the shape of the data. ## Spec compliance testing Standard tests verify that code does what the code does. Spec compliance tests verify that code does what the spec said. The rule: for every feature shipped through an agent-driven build, at least one test verifies a spec requirement the build's own generated tests did not cover. A different author, for a different purpose. Where these earn their keep: | Scenario | What to test | | --- | --- | | Data scoping | A query returns only the authenticated user's records, not all of them | | Authorization | An action blocked in the interface is also blocked at the API and the data layer | | Default state | A feature initializes to the specified default, not to the first option or a code-level default | | State persistence | A selection survives navigation | | Negative path | Invalid input is rejected, not silently accepted, defaulted, or crashed | | Contract | Field names, types, sort order and shape match the documented contract, not just a success code | ## Who owns what, and when Each artifact has one owner and one moment. | Artifact | When | Owned by | | --- | --- | --- | | The spec | Before build | Product | | The validation plan: scenarios per criterion, tags, edge cases, traceability | Before build | Quality | | The stack-layer mix: which scenarios run as unit, component, integration, end to end, or visual | In the plan | Engineering | | The test code | During build | Engineering, generated under supervision | | Review of whether the suite covers the spec | After build | Engineering | | Implemented spec compliance tests | After build | Quality, targeting the gaps the compliance-risk notes predicted | | Manual testing | After build | Quality, as a calibration tool and not as primary coverage | The boundary that matters: the build agent's tests verify the implementation is internally consistent. Quality's tests verify it matches the spec. Both are automated. Different authors, different purpose. Everyone in this workflow is working with an agent. Product with a spec agent, quality with a planning agent, engineering with a build agent. When this says "the build agent's tests", it means the one the developer drove during the build. ## Coverage scales up, never down Coverage should match the complexity and criticality of the work. A copy change and a new authentication flow do not need the same suite, but both need one. When in doubt about whether a behavior needs a test, write it. Generating the test is cheap now. Missing the behavior is not. ## The gates every change clears Gates are the baseline, not the coverage. Feature tests prove correctness. Gates enforce the floor. | Gate | What it enforces | | --- | --- | | Lint | Zero errors, not zero warnings | | Type check | No type errors and no suppressions | | Unit suite | Everything passes | | Coverage threshold | A minimum at project level, higher on security-critical paths | | Static security scan | Zero warnings | | Dependency scan | No high-severity vulnerabilities in production dependencies | A project-level coverage threshold is a lagging indicator. Auth, authorization middleware, payment processing and key enforcement need near-complete coverage regardless of what the project average says. **Gates must fail the build.** A gate that is installed and not enforced is decoration. If one is disabled, the reason is documented and the date it comes back is tracked. We have audited a project whose pipeline invoked a test command for a framework the team did not use: it found nothing, ran nothing, and reported green on every merge while 93 test files sat invisible. That is what an unenforced gate looks like from the outside. ## Traceability Every criterion maps to a test that proves it. The spec's job is to ensure the criterion exists before the build. The plan's job is to map it. A criterion with no test is not done, and a test with no criterion is not evidence. The [specification standard](https://www.koombea.com/ai-pods/standards/specification/) covers the other half of this, and the [readiness audit](https://www.koombea.com/ai-pods/ai-readiness-audit/) is how we find out where a project actually stands against both. ========================================================================== # How AI Pods Work > Story points, two-week cycles, and continuous deployment inside them. How a Koombea AI Pod turns your priorities into production software. Source: https://www.koombea.com/ai-pods/how-it-works/ --- A Pod runs one loop, repeatedly. Your priorities become specs, specs drive AI-First implementation, and automated gates decide what reaches production. ## The pipeline, end to end Traditional teams lose most of their time to handoffs. A product manager writes a ticket, an engineer interprets it, QA guesses at the intent, and the gap between those three readings becomes rework. A Pod removes the interpretation gap by making the spec the contract. Each item states its inputs, outputs, and edge cases before implementation starts. The scenarios that verify it are written from that same spec before the build, by someone other than whoever builds it. ### One item, four stages - Priority: You say what matters most this cycle - Spec: Inputs, outputs, edge cases, estimated in points - Build: AI-First implementation, reviewed before merge - Gate: Tests written from the spec, plus automated review, decide the merge ## From intent to production, in one tight loop Intake and Scoping: You share the goal. We break it into estimated, prioritized backlog items. (1 to 2 days) Spec and Design: Each feature gets a precise contract of inputs, outputs, and edge cases, plus clickable prototypes to validate direction before a line of code. (Hours, not days) AI-First Build: Implementation runs AI-First. We review and refine every output before it merges. (Continuous) Integrated QA: Scenarios come from the spec and are written before the build. The pipeline enforces them. Quality is a gate, not a phase. (Built in) Continuous Deployment: Automated pipelines ship reviewed work to production safely. (Continuous) Monitor and Maintain: AI-First monitoring feeds issues straight back into the backlog. (Always on) ## The loop, and the way back out of it ## Two-week cycles, continuous deployment inside them The cycle is a planning rhythm, not a release gate. Work reaches production as soon as it clears its quality gate, which is often several times a week. The two-week boundary is when we re-cut priorities with you and publish the capacity report. That separation matters. Releasing on a fixed fortnightly date forces finished work to sit and wait, and waiting work rots. Shipping continuously while planning on a rhythm gives you both a predictable conversation and a short path to production. ## We run the cadence. You do not staff it. A committed scope needs a real rhythm behind it. Every two-week cycle has planning at the start, a short daily stand-up, and a review at the end where delivered work is demonstrated and accepted. We run a retrospective after that. All of it happens whether you attend or not. What changes is how much of it lands on your calendar. You are in the Priority Sync and the end-of-cycle review, because those are the two moments where your decision actually changes the outcome. The rest reaches you asynchronously through your Delivery Manager and the weekly capacity report. Your team spends its time reviewing working software, not sitting in status meetings. ## Why that report is never late The report is generated from the delivery record rather than assembled for the meeting. The platform a Pod runs on carries each approved item from its spec contract through generated tests and automated merge gates, and records what shipped against the item it came from. Counting throughput is a read of that record. This is the part that makes a fixed commitment possible at all. You cannot promise throughput you cannot measure, and you cannot measure it by asking people how their week went. Nobody assembles the report, which is why it is never late and never flattering. ## How we verify before we build The order of these three documents is the whole method, and getting it backwards is why delivery with agents so often produces fast rework. First the spec: what gets built, for whom, and what done looks like, with the edge cases and the exclusions written down rather than left to inference. Then the validation plan, which commits to how each criterion will be proven. That plan is written before any implementation, because a test written after the code only asks whether the code does what it does. Only then the implementation plan, which is built from both, so whoever executes knows what they will be measured against before they start. One spec, three readers. Engineering builds from it, quality writes the scenarios from it, and design works the states and flows from it. When all three start from the same contract, the most common defect class disappears: three people building slightly different mental models of the same feature. It also means work does not start until all three inputs exist. If one is missing, that is the thing to say out loud, not the thing to work around. - Spec first, with edge cases and exclusions explicit, not inferred - Validation plan before implementation, never after - Implementation plan built from both, so nothing is discovered at build time - Engineering, quality and design all working from one contract - How complete the spec needs to be scales with the risk: anything touching auth, permissions or payments gets the full treatment ## What done means "Done" is the word most likely to mean two different things to the two people using it, so we define it twice. A single item is done when it is built, deployed to staging, and accepted by you in the end-of-cycle review. That is the bar that keeps a cycle moving, and it is deliberately a low ceremony one. A phase is a different matter, because phase acceptance is what starts the warranty. Every acceptance criterion has a passing test, every edge case we listed has a verification, coverage thresholds are met on the code we wrote, and no P1 or P2 defect is open. The production launch checklist is complete, we hand over the architecture overview and deployment runbook, and source and pipeline access is transferred to whoever you name. Then you sign off in writing, and the warranty clock starts. If any of those is not demonstrably true, the phase is not delivered, and we do not get to call it delivered because the calendar says so. - Every acceptance criterion has a passing test, every listed edge case a verification - No open P1 or P2 defects at handoff - Production checklist done, runbook and architecture overview handed over - Source code and pipeline access transferred to your named owner - Written sign-off from you, which is what starts the 30 day warranty ## What we need from you A Pod is fast because the inputs are small and structured. We need about an hour a week from one decision-maker who can approve deliverables and answer questions, and feedback on review items inside about three business days. That is the floor rather than the ceiling. You do not need to staff a project manager against us, sit in ceremonies, or maintain a backlog on our behalf, because your Delivery Manager does that and reports on it. Plenty of clients want to be in the detail every day, and that works too. The hour is what delivery requires, not a limit on your access. - About an hour a week from one named decision-maker with authority to approve - Feedback on review items within about three business days - Access to the systems the work has to integrate with ========================================================================== # Prototype to Production > A scoped AI Pod that takes a prototype built in Cursor, Lovable, v0, Bolt, Replit or Claude Code and makes it safe to put in front of customers. Source: https://www.koombea.com/ai-pods/catalog/prototype-to-production/ --- Someone built the thing in a weekend and it works. Then a real user found the second edge case. This Pod takes a prototype to production without throwing away what already works. ## The problem Prototypes built in Cursor, Lovable, v0, Bolt, Replit, Windsurf or Claude Code are genuinely useful. They answer the question of whether the product is worth building, in days, for almost nothing. That is a real advance and it is not the problem. The problem arrives the week someone wants to charge money for it. The auth is a placeholder. The data model has no migrations. There are no tests, no error handling on the paths nobody demoed, and an API key sitting in the client bundle. None of that was a mistake. It was the right trade for a prototype and the wrong one for production. We do not rewrite it. A rewrite discards the one thing the prototype proved, which is that this shape of product is worth having. - The working product loop survives the engagement - Findings are ranked by what blocks launch, not by what offends taste - You get the assessment as a standalone deliverable before committing to a build ## What this Pod ships - **Auth, secrets and access control**: Real authentication, keys off the client, and permissions enforced on the server rather than in the interface. - **A data model that can change**: Migrations, constraints, and a schema that survives its first production edit. - **Tests and gates**: Scenarios written from the spec, enforced in the pipeline, so the next change does not undo this one. - **Deploy, monitor, recover**: An automated pipeline, error tracking, and a documented path back when a release goes wrong. ## The assessment comes first The first stage is 15 to 25 points and stands on its own. We audit the prototype against the things that actually block a launch, and hand you a ranked findings list with a costed remediation plan. Sometimes that document says the honest answer is a rebuild, and we say so. Buying a small assessment to discover that is a much better outcome than discovering it four months into a hardening engagement. ## What it costs Two numbers, because these are two decisions. The assessment is 15 to 25 points and produces the estimate for the build. The build typically runs 100 to 250 points. That range narrows to a committed figure once the assessment is done. The assessment credits in full against the build if it starts within 90 days, the same window banked points run on. - Assessment: 15 to 25 points, two weeks, standalone deliverable - Build: typically 100 to 250 points, committed after the assessment - The assessment credits in full against the build if you start within 90 days - Your prototype, your repository, your IP throughout ========================================================================== # Capabilities > Eight capabilities, delivered by AI Pods against a committed scope. Product engineering, platform modernization, integrations, AI, quality, maintenance, design, and governance. Source: https://www.koombea.com/capabilities/ --- Eight capabilities, each delivered by an AI Pod against a committed scope. We list capabilities rather than technologies, because the stack is a delivery detail and the outcome is what you are buying. ## The eight capabilities What each capability is for, what gets built, and one piece of proof you can check. You buy every one the same way: an AI Pod, scoped into a work breakdown, estimated in story points, and priced before the work starts. - Product Engineering: Most first phases hand you scaffolding and call it progress. Yours is a complete loop instead. A user gets in, does the thing the product exists for, and gets a result. - Phase 1 is a usable product, never a stub - Web, native and cross-platform mobile, and the APIs behind them - Estimated in story points before the build starts - Luna went from nothing to a native app in market in three months. FlightLogger tracks over 1,500 airlines and more than 30,000 airports. - Platform Modernization: The system is not broken. Changing it is, and a one-week feature now takes six. We carve the platform into pieces and move them one at a time, behind an interface that does not change. - Incremental cutover, so a working system exists at every step - Zero-downtime migrations where the business cannot pause - A measured before-and-after on your cost of change - Payix arrived with a platform so rigid that creating a new client environment took months. Onboarding time dropped sharply. - Integrations and Data: Anyone can call an API in a demo. Production is what happens when the other system is slow, wrong, or briefly gone. Every integration drifts eventually, so each one ships with a way to catch it. - Idempotent operations, so a retry cannot double-charge - Reconciliation that finds drift before your customer does - Alerting on the business fact, not on the HTTP status - Jamar's store integrates pricing, inventory, payments and product data through STEP, with location-based segmentation for regional pricing. - AI Engineering: A prototype impresses a meeting. Production has to be right often enough to trust. That gap is evaluation, retrieval quality, guardrails, and a cost you can predict before the users arrive. - An evaluation set built before tuning, so you can measure a change - Retrieval treated as the main lever on correctness - Cost per operation modeled before volume, not after - ScopeGen AI turns a client conversation into an estimated work breakdown, which is why your scope can be priced before it is built. - Quality Engineering: Testing at the end is the first thing cut when a date slips. Here the tests come from the spec, written before the build, and they run as a gate on every merge. - Scenarios written from the spec, not from the finished code - A second author checks the build against the requirement - Regression suites that grow with the product instead of rotting - Our teams hold ISTQB and Certified Agile Tester credentials, and the software design and development unit is appraised at CMMI-DEV/3. - Maintenance and Support: Launch is the start of the expensive part. Dependencies deprecate, certificates expire, and volume outgrows an early decision. Handled continuously, that is a small and predictable draw on capacity. - A 30 day warranty on delivered software, then a monthly plan - Security and dependency upkeep on a schedule, not on an incident - Four severities with response targets, agreed before launch - Maintenance is why several of the engagements on our work page have run for years rather than months. - Product Design: A design that cannot be built as drawn is a picture. Design and delivery sit in the same Pod here, so a clickable prototype settles every flow before anyone implements it. - Clickable prototypes that settle direction before code - Design systems delivered as components engineering can use - Research sized to the decision, not to a template - This design work has won Indigo Design Awards for Luna, Nab, Fashioned Health and FlightLogger, including Gold for UX, Interface and Navigation. - Governance, Risk and Compliance: A working product is the easy half. The other half is showing an auditor why your handling of their data is defensible. This work is never story-point priced, because a policy set has no functional scope to count. - vCISO, ISMS design, and a risk treatment plan you can act on - Penetration testing you authorize in writing first - Gap analysis and accompaniment through certification - Fashioned Health was built on HIPAA-ready infrastructure with PCI-compliant payment handling through Stripe. We do not issue certificates, and no development partner does. ========================================================================== # Payments and Lending Software Development > Financial software development for payment platforms, lending products and collections. Idempotent by design, PCI-aware, built to reconcile. Source: https://www.koombea.com/industries/payments-and-lending/ --- Financial software is judged on the days it goes wrong. Idempotency, reconciliation, and a clear audit trail are the whole job. ## What makes this different Payments software has an unusual property: the happy path is easy and almost irrelevant. What determines whether a platform is trustworthy is what happens when a request times out after the charge succeeded, when a webhook arrives twice, or when two systems disagree about a balance. We build these products around those cases first. Every money-moving operation is idempotent, so a retry cannot double-charge. Every integration has a reconciliation job that detects disagreement rather than waiting for a customer to report it. Every state change leaves an audit trail you can hand to a regulator. On PCI DSS, the first move is always scope reduction. The cheapest compliance work is the work you engineer your way out of needing. - Idempotent money movement, so a retry is never a second charge - Reconciliation that detects drift between systems automatically - PCI DSS scope reduced by design before controls are added - Audit trails on every state change, built for review ## What we build here - **Payment platforms**: Gateways, wallets, and the onboarding flows that scale them. - **Lending and collections**: Servicing, repayment, and borrower-facing tooling. - **Reconciliation**: Automated detection of the disagreements that cost real money. - **PCI DSS**: Scope reduction first, then the controls the remainder requires. - **Processor integration**: Stripe and others, with idempotency and replay handled properly. - **Operational visibility**: Dashboards that show failures, not just volume. - **Onboarding, KYC and AML**: Identity and sanctions checks recorded as decisions you can replay. - **Mobile money movement**: Wallets, transfers, and cash-in and cash-out on the phone. - **Fraud and risk scoring**: Scored inline, with every decline explainable after the fact. ## Payments and lending are not the same build ### Payments — Money moves in seconds and has to be right the first time. The work is integration and correctness. A charge, a transfer or a payout crosses systems you do not control, each with its own retry semantics and its own opinion about when a thing is final. The product is judged on whether those opinions can be reconciled without a human reading a spreadsheet. - Gateways, checkout flows and one-click purchase paths - Digital wallets, stored balances, cash-in and cash-out - Domestic and cross-border transfers, with real-time status - Merchant and reseller onboarding, including the approval workflow - Settlement, payout and chargeback handling - Business intelligence on volume, decline reasons and failure rates ### Lending and collections — The balance is alive for years, and every touch of it is regulated. A loan is a payments problem with a memory. Interest accrues, schedules change, payments arrive early, late or partially, and the balance has to stay defensible across every one of those events. Collections adds a second constraint, because contact itself is regulated. - Origination and application flows, with decisioning kept auditable - Servicing, amortisation and repayment scheduling - Borrower self-service: balances, payoffs and payment arrangements - Collections workflow, contact rules and promise-to-pay tracking - Payment plan changes that reconcile against the original schedule - Statements and disclosures generated from the ledger, not restated Most platforms in this segment eventually do both. A lending product bolted onto a payments ledger inherits the wrong assumptions about how long a balance lives, and the correction lands years later in a reconciliation nobody can close. ## What we inventory before quoting The estimate on a payments build is driven by integration surface, not by screen count. Two products with identical interfaces can differ by a factor of three in effort because one of them settles through a single processor and the other reconciles four systems that each believe they hold the truth. So the first pass is an inventory. We list every system that touches money or identity, establish which of them is authoritative for each fact, and find where they can disagree. That list is what gets estimated in story points, and it is why the number holds. ### The integration inventory - Processors and acquirers: Which ones, in which markets, and what each considers final - The ledger: Whether one exists, whether it is authoritative, and who writes to it - Bank rails and payout paths: ACH, wires, local rails, and the settlement windows each imposes - Identity, KYC and sanctions vendors: Where the decision is made and whether it can be replayed later - Webhooks and event delivery: Every endpoint that can fire twice, out of order, or not at all - Card data touchpoints: Every place card data currently lands, which sets your PCI scope - Reporting and finance systems: What finance reconciles against today, and how often it disagrees ## How a payments build reaches production The order matters. Correctness decisions taken after a flow ships are audits of every write path you already wrote. Inventory and scope: Every money-touching system is listed, the authoritative source for each fact is named, and the disagreements are found on paper. The scope comes out of that list and is priced before anyone builds. (Integration inventory, story point estimate, committed scope) Ledger and idempotency design: The money model is decided first: what a transaction is, what states it can hold, and which key makes an operation safe to repeat. Idempotency is defined at the point each operation is defined, because retrofitting it means auditing every write path already shipped. (Money model, idempotency keys, state machine) PCI scope reduction: Flows are engineered so card data lands in as few systems as possible, normally by pushing capture to the processor. What remains in scope is then controlled deliberately rather than inherited by accident. (Tokenisation, hosted capture, scope boundary) Integration and replay: Processors, rails and vendors are wired with duplicate delivery, out of order events and missing callbacks treated as normal traffic rather than incidents. Every inbound event is replayable against the ledger. (Webhooks, retries, event replay) Reconciliation and observability: Automated jobs compare the ledger against each external system on a schedule and raise the differences. Dashboards report declines, timeouts and unreconciled items, because volume alone hides all three. (Reconciliation jobs, alerting, failure dashboards) Attestation and handover: Controls and evidence are packaged for whoever signs off, and the documentation is produced from the work rather than reconstructed afterwards. IP assignment happens on full payment, automatically and in the contract. (Written security attestation, runbooks, IP assignment) ## Proof from this segment Figures published by the clients themselves. - Daily transactions at Paymentez: Up from 4,000, after the gateway and its flows were rebuilt - LAN house resellers in one year: Growth the previous flows could not be provisioned fast enough to serve - Conversion increase in six months: From showing each user only the actions relevant to them "Today's user experience is completely different than it was in the past. Now users are presented with only the actions and flows that are directly relevant to them." Miguel Ramirez, CPO, Paymentez ## Where payment projects usually go wrong Four failures account for most of the money lost in this segment, and none of them are exotic. They are the cases that never make it into a demo, which is exactly why they are still there at launch. - A retry path that was never tested under a timeout, so a customer is charged twice and support finds out before engineering does - Webhooks treated as reliable, so a duplicate delivery moves money a second time and an outage silently drops a settlement - Reconciliation deferred to a later phase, which means the first disagreement between systems is discovered by a customer - PCI scope accepted as given rather than engineered down, so the compliance bill is set before the architecture is ## Where a model earns its place Machine learning is routine in this segment, and it is worth being specific about where it pays. Fraud scoring, credit decisioning, and collections prioritization are the three places a model beats a rule set, because each is a ranking problem over data you already hold. The constraint is that a model here produces decisions about people, and those decisions have to be explainable after the fact. An applicant declined for credit is owed a reason, and a disputed transaction is reviewed by someone who was not in the room. So we store the features and the score alongside the decision, version the model that produced it, and keep a rules path that can override it. A score that cannot be reconstructed six months later is a liability rather than an asset. We also say plainly when a model is not the answer. Most fraud caught in the first year of a new platform is caught by velocity limits and a blocklist, and a model trained on a few thousand transactions mostly learns the shape of your test data. - Fraud and chargeback scoring, with the features and score kept alongside the decision - Credit and affordability decisioning, versioned so any decline can be reconstructed - Collections prioritization, ranking accounts by likely recovery rather than by age - Anomaly detection on reconciliation breaks, surfacing drift before finance finds it ## How teams arrive here - **A new product**: A first payments or lending product, where the pressing risk is building the wrong correctness model and discovering it in production. - **An enterprise platform**: An existing platform that has to scale, integrate or be modernized without pausing the money moving through it. - **A rescue**: A build that has stalled or lost its team. Payix arrived this way, and the first work was architectural rather than cosmetic. - **A plan before a build**: Scoping only: the integration inventory, the correctness model and a priced backlog, whether or not we build it. ## How fintech work is scoped and priced Payment and lending builds are delivered by AI Pods against a committed scope, estimated in story points and priced before work begins. The estimate comes out of an integration inventory, because processor and ledger surface is what actually drives effort here. Compliance work is the exception and is never story-point priced. Audit and attestation are scoped as a retainer or a fixed fee, because the deliverable is an opinion rather than a feature. ## Partnerships and certifications ## Questions worth asking ### What does fintech software development actually involve? In practice it is integration and correctness work far more than interface work. Processor and ledger integration, idempotent money movement, reconciliation between systems that will disagree, and an audit trail a regulator can read. The screens are the visible part and the smallest part of the estimate. ### Can you reduce our PCI DSS scope? Usually, and it is the first thing we look at. Scope reduction means engineering the flow so that card data never touches systems you would otherwise have to certify, normally by pushing capture to the processor. The cheapest compliance work is the work you engineer your way out of needing. ### How do you keep a retry from double-charging? Every money-moving operation carries an idempotency key, so a repeated request resolves to the same result rather than a second charge. That has to be designed in at the point the operation is defined. Retrofitting it means auditing every write path you already shipped. ### Do you work with our existing processor? Yes. We are a Stripe Verified Partner and have built against Stripe extensively, but the pattern is processor-agnostic and most platforms in this segment run more than one. What matters is that replay, settlement and reconciliation are handled the same way regardless of which one is behind the call. ### Can you build lending and collections, not just payments? Yes. Servicing, repayment scheduling, borrower-facing tooling and collections workflow are in scope, and Payix is a case study in exactly that. The correctness constraints are the same ones payments has, with a longer-lived balance to keep accurate. ### Do you build mobile banking and wallet products? Yes, and the hard part is rarely the app. A wallet is a stored balance, which means it is a ledger with a customer attached, so the questions are the same ones a payments platform answers: what makes a balance authoritative, what happens when a top-up succeeds after the client gave up, and how the balance reconciles against the rail behind it. ### Can you handle KYC, AML and sanctions screening? Yes, as an integration and an evidence problem rather than as a policy one. Your compliance team or counsel sets the policy. We wire the vendors, record each check as a decision with its inputs and its outcome, and make those decisions replayable, because a screening result you cannot reconstruct is not evidence when someone asks. ### Do you use machine learning for fraud or credit decisions? Where the data supports it. Fraud scoring, credit decisioning and collections prioritization are the three cases that reward a model. We keep the features and the score with the decision and version the model behind it, so any outcome can be reconstructed and explained later. On a new platform with thin history we start with velocity limits and rules, because a model trained on a few thousand transactions mostly learns your test data. ### What about crypto and digital assets? We have built in this space, and the honest framing is that custody and key management are the deciding constraints rather than the trading interface. If you hold customer assets, the risk model is closer to a bank's than to a payments gateway's. We will tell you during scoping which parts of that we would take on and which belong with a specialist custodian. ### How long does a payments build take? It depends almost entirely on the integration inventory, which is why we build that first and quote from it rather than from a category average. A gateway settling through one processor and a platform reconciling four systems look similar as products and differ by a factor of three in effort. ## Where to go next The integration inventory is what sets the estimate here. These three case studies show what that inventory turned into. - Payix: Case study: a rigid payment platform where standing up a client took months, rebuilt so it does not - Paymentez: Case study: a gateway rebuild that moved daily transactions from 4,000 to 120,000 - Tuily: Case study: corporate credit for Colombian SMEs, built from an idea and acquired by Bold - Integrations and Data: The capability this segment leans on most, including the reconciliation that catches drift before a customer reports it ========================================================================== # StorefrontOS > Launch native iOS and Android apps on your existing Shopify store in 2 to 3 weeks, on a fixed scope, without rebuilding cart and checkout. Source: https://www.koombea.com/products/storefrontos/ --- Launch on iOS and Android in 2 to 3 weeks from kickoff, on a fixed scope. The commerce foundation is already built, so the work goes into your brand. ## Stop rebuilding mobile commerce infrastructure Every mobile commerce project rebuilds the same things. Cart. Checkout. Authentication. Order history. Product variants. None of it is differentiating, and all of it takes months. StorefrontOS ships that foundation production-ready and synchronized with Shopify. What remains is the part that is actually yours: how the store looks, how it merchandises, and how it speaks. - Launch in 2 to 3 weeks from kickoff - Roughly 80% less engineering scope, focused on brand rather than plumbing - One price for the scope you signed, with no change-order surprises - Direct Storefront API integration, so there is little new backend to run - An owned customer channel, independent of marketplace apps ## StorefrontOS, or building it again | | Building from scratch | On StorefrontOS | |---|---|---| | Time to launch | 3 to 6 months from kickoff, every project, because the foundation is rebuilt each time. | 2 to 3 weeks from kickoff. The production foundation exists on day one. | | What the engineering buys | Cart, checkout, auth, variants, and order history, built from zero. | Brand, content, and merchandising. Roughly 80% less scope, aimed at the part that is yours. | | How it is priced | An estimate, plus the change orders nobody warned you about. | Fixed scope, one price, agreed before work starts. | | The backend you run | A parallel commerce backend to design, secure, and scale. | None. Native clients read the Shopify Storefront API directly. | | Who owns maintenance | You do, and it compounds. Every OS release is another sprint. | We do. OS updates, SDK changes, and security patches come with the platform. | | Where the catalog lives | Synced into a second system, then reconciled when the two disagree. | Shopify stays the source of truth for products, inventory, pricing, and customers. | ## Six stages, already engineered - **Discover**: Customizable home modules with CMS-controlled layouts. - **Browse**: Product grids with filters, search, and variant previews. - **Detail**: Product galleries with native add-to-cart. - **Convert**: A native cart handing off to Shopify checkout. - **Retain**: Customer profiles, order history, and authentication options. - **Operate**: Real-time Shopify sync, push notifications, multi-market support, analytics. ## Built directly on Shopify, with minimal backend The native clients talk to the Shopify Storefront API. There is no intermediate commerce service holding a second copy of your catalog. StorefrontOS Core sits on top of that and handles the parts an app needs and a storefront does not: UI, state, routing, the content layer for home modules and editorial, sync, and analytics. Products, inventory, pricing, customers, and orders stay in Shopify, where your team already manages them. Checkout hands off to Shopify's own checkout, including Shop Pay and Apple Pay. That keeps PCI scope where it already sits rather than extending it into your app. - Fewer moving parts, so fewer places for it to fail - No parallel commerce backend to design, secure, or scale - Lower total cost of ownership, because there is less of it to own - Shopify stays the source of truth, so your team's workflow does not change ## Three Moves to a Native App Connect the store: Products, collections, inventory, pricing, and customers sync through the Storefront API. No data migration and no parallel system, because nothing is being copied anywhere. (Storefront API, webhooks, multi-store) Make it yours: Color, typography, navigation, home layouts, and editorial content are configured. This is where the engineering scope goes, and it is the only part that is actually about your brand. (Theme tokens, home CMS, brand assets) Ship to both stores: Submission to the App Store and Google Play on the StorefrontOS release pipeline. Content and merchandising updates ship afterwards without another app review. (App Store, Google Play, over-the-air updates) ## Ships as Your Brand, Not a Template One foundation, three merchants. Color, typography, layout, navigation, and content modules are all yours to shape. The plumbing stays out of sight. ## What this replaces in practice A traditional mobile agency will typically quote three to six months and a six-figure budget for the same outcome, because they are quoting the reconstruction of commerce basics alongside your brand. StorefrontOS is a fixed-scope engagement. The exact figure depends on what your store needs, which we establish on a discovery call rather than by publishing a number that would be wrong for most merchants. ## Book a 30-minute demo We look at your store before the call, so what you get is a launch plan for yours rather than a generic walkthrough. You leave with engineering scope and a fixed timeline in writing. ## Everything Merchants Ask First ### Why not just use the Shop app or a responsive site? The Shop app is Shopify's marketplace, so your customers land in a feed alongside every other merchant. A responsive site cannot reach push notifications, deeper iOS and Android features, or the home screen. A native app on StorefrontOS is your own channel: your icon, your push, your brand end to end. ### What happens to my Shopify store? Nothing changes. Your admin stays the source of truth for products, inventory, pricing, customers, and orders. The app reads the Storefront API in real time and checks out through Shopify's own checkout, including Shop Pay and Apple Pay. No migration and no parallel system. ### Do I own the app and the code? You own your brand experience, your customer data, your push channel, and your App Store listings. StorefrontOS is the platform underneath, and we maintain it so OS updates, SDK changes, and security patches arrive without a rebuild. The relationship is close to the one Shopify already has with your store: the platform is managed, the brand is yours. ### Will it really launch in 2 to 3 weeks? Yes, because the commerce foundation is already built and tested. Those weeks cover connecting Shopify, brand customization, content configuration, QA, and submission to both stores. What moves the date is content readiness on your side, not engineering on ours, and we will say so during scoping if that looks like the risk. ### How much does it cost? It is a fixed-scope engagement: one price, one timeline, no change-order surprises. The number depends on how deep the brand and content work goes. A 30-minute call is enough to scope it against your store and send a written quote. ### What if I need custom features later? StorefrontOS is modular, so extending it is a scoped piece of work rather than a rewrite. Loyalty, subscriptions, and custom merchandising are the common ones, and they get priced in story points like any other scope. ### What about Android? iOS is the primary platform at launch and Android is shipping shortly. If Android is critical for your market, say so on the demo call and we will share the current timeline rather than a hopeful one. ## Where to go next - Shopify Plus Agency: The replatform and integration work around the store itself - Retail and Commerce: The segment this sits in - Do it Center: Case study: online and in-store on one platform - How Pricing Works: How fixed scope gets set ========================================================================== # Naples, Florida > Koombea's United States office. 3811 Airport Road N, Suite 100A, Naples, FL 34105. Source: https://www.koombea.com/locations/naples/ --- Naples is where our US-facing work is based. Delivery runs from Barranquilla, on Eastern time, with a full business day of overlap. ## The office 3811 Airport Road N, Suite 100A, Naples, FL 34105, United States. This is our United States base. Engineering happens in Barranquilla and across a remote-ready team, which is a deliberate structure rather than an accident: one delivery center keeps a Pod together, and one time zone keeps it reachable. - 3811 Airport Road N, Suite 100A, Naples, FL 34105 - Eastern time, matching the Barranquilla delivery center - Reachable on +1-888-840-3252 ========================================================================== # How We Work > The operational detail buyers ask for: working hours, time zone overlap, communication cadence, escalation, and what happens when something breaks. Source: https://www.koombea.com/company/how-we-work/ --- Time zone overlap, who you talk to, how often, and what happens at 2am when something breaks. None of this is interesting until it is the only thing that matters. ## Time zones and overlap Our delivery teams work Colombia hours, 9:00 to 18:00, and Colombia does not observe daylight saving. US Eastern does. So for the winter months we are on the same clock as New York, and from March to November we are one hour behind it. Either way our working day sits inside the US Eastern business day all year, and inside most of Central and the Pacific morning. Compare that to a team eight hours away with a two-hour window. - Colombia hours, 9:00 to 18:00, with no daylight saving shift - Inside the US Eastern business day year round, differing by at most one hour seasonally - Same-day response and live collaboration across the full working day - Working morning overlap with US Pacific ## Who you talk to One named Delivery Manager owns your product direction, priorities and communication. They are your single point of contact, and they are reachable without a meeting invite. That is deliberately one person. Multi-threaded communication into a delivery team sounds like access and functions like noise, because nobody ends up owning the answer. ### The cadence - Priority Sync: 20 to 30 minutes, weekly or fortnightly by tier - Async updates: Continuous, in your channel of choice - Capacity report: Weekly, generated from delivery data - Delivery review: Monthly on Growth and above ## When something breaks Production issues follow four severities agreed before launch rather than argued about during an incident. A P1 is a core flow down with no workaround, and it gets an initial response within two business hours. A P4 is cosmetic and gets prioritized into the backlog. Every level in between has a response target written into the engagement. These are business-hours targets on reproducible defects in code we wrote, and they apply while a support plan is active. Where a third party controls the fix we will investigate and contain, but we will not promise you a resolution window that is not ours to give. Escalation goes to your Delivery Manager first and then to a named engineering lead. If you ever need to escalate past both, the route to leadership is short, because the company is not large enough for it to be otherwise. - Four severities agreed in writing before launch, not during an incident - P1 response within two business hours, with targets attached to every level - Escalation to a named engineering lead, then to leadership - Post-incident review that feeds fixes back into the backlog ## What we need from you One decision-maker who can approve deliverables and answer questions, and feedback on review items within about three business days. Access to the systems the work has to integrate with. That is the whole list. Keeping the asks small and structured is what keeps delivery fast, and it is why you do not need to staff a project manager against us. ========================================================================== # AI Pods Pricing > How AI Pods are priced: story points, monthly capacity tiers, banked points, and the 90-day expiry. Published rather than buried. Source: https://www.koombea.com/ai-pods/pricing/ --- You buy story points, either as a fixed-bid scope or as a monthly capacity commitment. Here is the whole structure, including the parts most vendors leave in the contract. ## One honest unit of work We estimate every item of work in story points, on a simple 1, 2, 3, 5, 8 scale. Points track functional scope, integration complexity, and test coverage, which are the real drivers of effort. A point means the same thing in month one and month twelve. Nothing larger than an 8 enters the backlog. If an item estimates higher, we break it down until each piece is something we can commit to with confidence. That decomposition happens before you approve anything. ## Pick your capacity. Change it as you grow. ### Starter - Delivery lanes: 1 lane - Monthly capacity: 80 to 100 points - Best for: A focused product stream - Kickoff: Initial planning session - Priority Sync: Every 1 to 2 weeks, 20 minutes - Delivery review: Not included ### Growth - Delivery lanes: 3 lanes - Monthly capacity: 240 to 300 points - Best for: A product team's full roadmap - Kickoff: Deep planning: architecture and roadmap - Priority Sync: Weekly, 30 minutes - Delivery review: Monthly, 30 minutes ### Scale - Delivery lanes: 5 to 7 lanes - Monthly capacity: 400 to 700 points - Best for: Multi-product portfolios - Kickoff: Multi-day onboarding - Priority Sync: Weekly plus async report - Delivery review: Monthly, 45 minutes ### Enterprise - Delivery lanes: 10 or more lanes - Monthly capacity: From 800 points - Best for: Org-wide delivery programs - Kickoff: Full onboarding program - Priority Sync: Weekly plus async report - Delivery review: Bi-weekly Monthly capacity is quoted as a range because a lane commits at the lower bound and typically delivers above it. The commitment is the floor you are invoiced against, not a forecast we are asking you to trust. ## The terms most vendors leave in the contract A capacity commitment only works if you know what happens to capacity you do not use. Here is our answer. - Banked points: on a capacity commitment, a month that lands under the commitment banks the difference. A heavier month draws it back down before anything extra is invoiced. - 90-day expiry: banked points carry forward on a rolling 90 days, are not redeemable for cash, and are forfeited if the engagement ends. - Retainer balance: on a fixed-bid engagement your deposit is held as a retainer and drawn down against delivered points. Every invoice states the points delivered and the balance remaining. - Warranty: 30 calendar days on delivered software, running from your written acceptance of the production launch. - Change orders: any work not in the scope is estimated in points and priced before it starts. There is no penalty for a change order, because changing your mind is product learning, not a breach. - AI model costs: you are never billed per AI call or per seat. Model tokens are covered up to a monthly allowance. Anything above it is passed through at cost, with no markup, within a model configuration you approve in advance, and reported every week. - Token overage: any overage is invoiced monthly in arrears as a separate line item, supported by the provider's usage records, and never changes the price of a user story. The allowance does not carry over and is not redeemable for cash. ## What is not priced in points Governance, risk and compliance work is never story-point priced. Audit and attestation work is scoped as a retainer or a fixed fee, because the deliverable is an opinion rather than a feature. Fixed-scope specialist deliverables, such as a penetration test or a load-testing engagement, are priced upfront and drawn from your existing lane rather than opening a second billing track. ========================================================================== # Integrations and Data > API integration services, system integration, data pipelines, and the reconciliation work that makes systems agree under load. Delivered by an AI Pod. Source: https://www.koombea.com/capabilities/integrations-and-data/ --- Anyone can call an API in a demo. Production system integration is about what happens when the other system is slow, wrong, or briefly gone. ## The problem Most of the genuinely hard work in modern software is not building a feature. It is making two systems that were designed separately agree about the same fact, continuously, while both keep changing. That work is where projects actually fail. A payment that posted twice. An inventory count that drifted. A webhook that arrived out of order at 2am and nobody noticed for a week. We treat integration as a first-class engineering problem with its own failure modes: idempotency, retries with backoff, reconciliation, and alerting that tells you the truth. Every integration ships with a way to detect and repair drift, because every integration eventually drifts. - Idempotent operations, so a retry cannot double-charge or double-post - Reconciliation jobs that detect drift rather than waiting for a customer to find it - Ordered and replayable event handling, not fire-and-forget webhooks - Alerting on the business fact, not just on the HTTP status ## What this covers - **API integration**: Payments, ERP, EHR, logistics, identity, and the long tail of internal systems. - **Data pipelines**: Moving and reshaping data with the lineage to prove what happened. - **Reconciliation**: Automated drift detection between systems that must agree. - **Failure design**: Retries, backoff, dead-letter handling, and idempotency keys. - **Load behavior**: Verified against the volume and burst pattern you actually see. - **Secrets and access**: Credential handling that survives an audit. ## The other half: getting answers out Moving data correctly is the first job. The second is that somebody in your business wants a number, and right now they either ask an engineer or they trust a spreadsheet that has been wrong since March. We build the reporting layer as part of the product rather than as a project that starts after it. That means a warehouse or a reporting store fed by the same pipelines, metrics defined once so two dashboards cannot disagree, and lineage you can follow backwards when a figure looks wrong. The definition of a metric is the deliverable. The chart is the easy part. Where the question is genuinely exploratory we will say so, and we would rather connect your existing tool to a clean model than sell you a dashboard build you did not need. - A reporting store fed by the same pipelines, so operational and analytical data cannot drift apart - Metric definitions written once and shared, so two dashboards cannot disagree about revenue - Lineage from the number on the screen back to the row that produced it - Event tracking designed with the product, because retrofitted analytics measure the wrong things - Your existing BI tool connected to a clean model where that is the cheaper answer "Koombea's expertise in integrations with other systems and APIs has provided the knowledge necessary to solve many integration issues, which has been critical to our success." Andrea Jaramillo, E-Commerce and Digital Marketing Director, EPK ## What drives the estimate Integration work is where fixed-bid pricing gets tested, because half the cost lives in the other party's system and none of it is visible from a feature list. We size it from the failure modes rather than from the endpoint count. The single biggest driver is whether the partner system is well-behaved. A documented, versioned, idempotent API with a sandbox is a fraction of the cost of an undocumented SOAP endpoint that returns HTTP 200 with an error in the body. - Whether a sandbox exists, because testing against production is a cost and a risk - How the partner behaves on failure: does a retry duplicate, and can you tell - Whether events arrive ordered, and what you must do when they do not - Volume and burst pattern, which decide whether queues and backpressure are needed at all - Whether the two systems must agree continuously or can reconcile nightly, which is an architecture decision, not a preference ## The layers underneath - **Queues and caching**: Redis for caching and queueing, with background workers sized to the burst pattern rather than the average. - **Observability**: Datadog for application and infrastructure monitoring, CloudWatch where the workload is AWS-native. - **Secrets and access**: A managed secrets store with least-privilege access, chosen against your environment rather than ours. - **Contract tests**: Tests that fail when a partner changes their payload, before your customers find out. - **Security in the pipeline**: Dependency scanning, static and dynamic analysis running as gates rather than as an annual review. - **Infrastructure as code**: Terraform and Docker where the engagement includes provisioning, so an environment is reproducible. ## Questions worth asking ### The system we need to integrate with has no documentation. Now what? That is common and it is priced as discovery rather than guessed at. We probe the interface, document the real behavior including the undocumented failures, and estimate the integration from that. Skipping this step is how integrations become the thing that overran. ### Who owns it when the partner API changes and something breaks? Contract tests mean we usually find out before you do. Under an active support plan a break in code we wrote is ours to fix within the agreed severity target. Where the fix is genuinely on the partner's side we investigate, contain, and coordinate, but we will not promise you a resolution window that is not ours to give. ### Do you build the reconciliation, or do we? We build it, and we treat it as part of the integration rather than as a phase two nicety. Every integration eventually drifts. The question is only whether you find out from a job or from a customer. ### Can you work with our data team rather than around them? Yes, and this is one of the cases where Staff Augmentation is often the better purchase. If your team owns the warehouse and the backlog, buying a committed scope adds a layer you do not want. ### We already have a BI tool nobody uses. Is that a data problem? Usually it is a modeling and definition problem wearing a tooling costume. Before recommending anything new we look at whether the underlying model can answer the questions people are actually asking. ## Four systems, one reconciled store Jamar's store integrates pricing, inventory, payments and product data through STEP, with location-based price segmentation for a regional pricing model. ========================================================================== # AI Readiness Audit > What an AI readiness audit actually measures: four dimensions scored on evidence, every finding tagged by how strongly it is supported, and a gap list ranked by what it puts at risk. Source: https://www.koombea.com/ai-pods/ai-readiness-audit/ --- ## The four dimensions Each dimension maps to one published or in-progress standard, so a score is a position against a written bar rather than an opinion. | Dimension | What it measures | | --- | --- | | Delivery | Whether the pipeline enforces quality before code reaches production: lint, type check, tests, static security scan, dependency audit, coverage threshold, build | | Observability | Whether the running application can be diagnosed: error tracking, performance monitoring, structured logging, health checks, alert routing, and agent telemetry | | Validation | Whether test coverage exists across layers for each area of the product, with traceability from each acceptance criterion to a test that proves it | | Specification | Whether work items carry enough information for an agent to implement them correctly, measured on required fields and completeness tiers | Eight other systems make up a project, and this audit does not score them. Findings there get noted as context. The [twelve systems](https://www.koombea.com/ai-pods/standards/) page covers the full picture. ## How a score is set {#scoring} Each dimension scores zero to three against its standard. The score is not a grade on the team. It is a statement about what a change passes through today. Gaps are then ranked by consequence, not by how easy they are to fix. | Severity | What it means | | --- | --- | | Critical | Broken code or a security vulnerability can reach production with no automated check | | High | A core area is uncovered, or existing tooling is misconfigured enough to be misleading | | Medium | A missing practice that raises risk but has a workaround | | Low | An improvement worth making that is not blocking anything | Where a dimension's standard is still being finalized, gaps are flagged and not counted as failures. The bar is not finished, so scoring against it as though it were would be unfair to the project. ## How it runs {#how-it-runs} Access is verified first. Whatever cannot be reached is recorded as inaccessible, and the missing access becomes a finding in its own right rather than a hole filled with an assumption. Then evidence is collected per dimension by reading the sources directly. The pipeline configuration, not a description of it. The test suite, not the coverage badge. The work items, not a sample someone selected. ## The rules that keep it honest {#integrity} These govern the auditor, not the project. They are the reason the output is worth acting on. - **Evidence first.** A gap is never filled with an inference. If a source cannot be reached, the finding is tagged as blocked and the audit moves on. - **Every claim carries a strength tag.** Verified means confirmed by reading the source. Inferred means derived indirectly, and says so. Blocked means the source was unreachable. - **Exact counts over percentages.** When all items can be counted, the exact number is reported. When sampling is necessary, the sample size is stated and nothing is extrapolated without labelling it. - **Ask before sampling.** Reading twenty of a hundred work items is agreed in advance, and sample conclusions are never carried forward as facts once the full set becomes available. - **Classify before writing.** Every data point is tagged before a section is drafted, and classifications are never mixed inside one claim. - **Evidence and interpretation stay separate.** Raw data lives in evidence files. The report cites them rather than re-embedding them. - **Re-verify on new access.** When a blocked source opens up, the affected sections are redone from scratch rather than patched. - **Frame for the reader.** The same evidence is emphasized differently for a quality lead than for a delivery lead. The evidence does not change. ## What you get back {#what-you-get} - A four-row maturity dashboard: dimension, score, what the score is based on, and the finding that mattered most - A methodology note listing which sources were read and which were unreachable - A per-dimension comparison of the standard against the current state - One consolidated gap list, ranked by severity - Remediation recommendations, when you want them ## What this looks like when it goes badly The reason this audit reads sources instead of asking questions is that the interesting findings are invisible from the inside. On one project the backend pipeline invoked a test command for a framework the team was not using. It found nothing, ran nothing, and reported green on every merge, while 93 test files sat in the repository and never executed. Everyone involved believed tests were running. The badge said so. The frontend on the same project had no quality gates at any stage, and none of the five observability layers we look for, with a comment where error reporting should have been. Neither finding required judgment. Both required looking. ## Then what A gap list is not a plan. If you want the gaps closed, the [compliance readiness](https://www.koombea.com/ai-pods/catalog/compliance-readiness/) and [test automation](https://www.koombea.com/ai-pods/catalog/test-automation/) Pods are scoped and priced for exactly this work, and the [standards](https://www.koombea.com/ai-pods/standards/) the audit scores against are published so you can close them without us. ========================================================================== # Industrial and Field Service Software Development > Software for field crews and industrial operations: offline-first mobile, device integration, and scheduling that survives real conditions. Source: https://www.koombea.com/industries/industrial-and-field-service/ --- Field software is judged in a basement, a plant, or a truck at the edge of coverage. If it needs the network to function, it does not function. ## What makes this different Industrial and field service products break in ways office software never does. The user is wearing gloves, the tablet is in direct sunlight, the connection drops for forty minutes, and the job still has to be recorded correctly. That makes offline-first a structural decision rather than a feature. Work has to be capturable locally, queued, and synchronized later without losing data or creating duplicates when two crews touch the same record. Conflict resolution has to be designed rather than discovered. We also treat hardware as part of the product. Barcode scanners, Bluetooth sensors, printers, and rugged devices behave unpredictably, and the only way to know a product works with them is to test on the actual hardware. - Offline-first capture with conflict resolution designed, not improvised - Tested on the real devices crews carry, not just in a simulator - Scheduling and dispatch that hold up when the day changes at 7am - Bluetooth, IoT and peripheral integration verified on hardware ## What we build here - **Field operations**: Work orders, inspections, and asset records captured on site. - **Rugged and peripheral devices**: Scanners, sensors, printers, and the quirks each one brings. - **Offline sync**: Queued writes, ordered replay, and deliberate conflict handling. - **Scheduling and dispatch**: Routing and reassignment that survive a changing day. - **Operational reporting**: What was done, by whom, and when, from the field record. - **Safety and compliance records**: Evidence captured as part of the job, not afterwards. ## Proof from this segment Reference engagements are available under NDA in the Priority Sync. ## Where to go next - Do It Center: Case study: unified order and inventory management with point-of-sale and accounting integrated, where the operations layer was the project - Jamar: Case study: STEP master data and regional pricing kept in agreement across the systems that already held them - Integrations and Data: The capability this segment leans on most, including the reconciliation that finds drift before a customer does - Product Engineering: Offline-first decided at the architecture stage, which is the only stage where it is cheap ========================================================================== # Industries > Five segments where we have delivered repeatedly: health services, payments and lending, industrial and field service, retail and commerce, technology. Source: https://www.koombea.com/industries/ --- Domain knowledge is the difference between a product that works and one that fits. These are the five segments where we have built enough to know the failure modes before we meet them. ## Where we work What each segment demands, what we build there, and one piece of proof you can check. - Health Services: A clinical product has to fit how care is delivered, and it has to prove how it handles patient data. Both are design problems before they are engineering problems. - Patient and clinician surfaces built separately, because they do not want the same product - EHR and practice-management integration, with the reconciliation it needs - HIPAA evidence produced during the build, not reconstructed before an audit - Luna reached the market in three months. Thousands of therapists now work on it, serving tens of thousands of patients. - Payments and Lending: A payment product is judged on the days it goes wrong. Idempotency, reconciliation, and an audit trail you can hand to a regulator are the whole job. - Idempotent money movement, so a retry is never a second charge - Reconciliation that detects drift before a customer reports it - PCI DSS scope reduced by design before controls are added - Paymentez went from 4,000 daily transactions to 120,000 after the gateway and its flows were rebuilt. - Industrial and Field Service: Field software is judged in a basement, a plant, or a truck at the edge of coverage. If it needs the network to function, it does not function. - Offline-first capture with conflict resolution designed, not improvised - Tested on the real devices crews carry, not in a simulator - Scheduling and dispatch that survive a day that changes at 7am - Reference engagements are available under NDA in the Priority Sync. - Retail and Commerce: The storefront is the visible part. What decides whether it works is inventory, pricing, and fulfilment, and whether the systems behind them agree. - Unified inventory and order management across channels - POS, ERP and accounting integration, with reconciliation - Native mobile commerce in 2 to 3 weeks through StorefrontOS - A Shopify Plus Partner since 2018. Do It Center's replatform cut bounce rate by 90% and reached an NPS of 70. - Technology: Technology companies do not hire a partner for capability. They hire one for throughput on a specific bet, without slowing the team they already have. - Multi-tenant SaaS, including the tenancy decisions that are hard to reverse - Platform APIs and developer experience treated as product surface - Modernization delivered incrementally, with a working system at every step - FlightLogger tracks over 1,500 airlines and more than 30,000 airports, with tens of thousands of monthly active users. ## If your sector is not here That does not mean we cannot help. It means we will not claim specialist knowledge we have not earned. Bring the problem to a Priority Sync and we will tell you honestly whether it plays to our strengths. ========================================================================== # MVP Launch > A scoped AI Pod that ships a first version customers can actually use, at a price agreed before work begins. 200 to 400 story points. Source: https://www.koombea.com/ai-pods/catalog/mvp-launch/ --- A first release that runs a complete loop in production: a user arrives, does the thing the product exists for, and the business sees it happen. Priced before work starts. ## The problem The standard first phase delivers infrastructure. A login screen, a database, a deployment pipeline, an admin panel. All of it necessary. None of it usable by a customer. Every penny of it spent before anyone learns whether the product works. That sequencing serves the build, not the business. It also makes the second funding conversation much harder, because you are asking for more money against a demo of a login screen. We sequence the other way. Phase 1 is a narrow slice of the product cut end to end, in production, doing the one thing that matters most. The infrastructure gets built because that slice needs it, not before. - A real user can complete the core journey on the day it launches - The narrow slice proves the product before the budget grows - Later phases widen it rather than finally connecting it ## What this Pod ships - **Specs and prototype**: Each item a contract of inputs, outputs and edge cases, with the core flows validated as clickable screens first. - **The product, web or mobile**: The end-to-end journey built and running, on the platforms your users are actually on. - **Tests written from the spec**: Scenarios authored before the build, enforced as merge gates, so quality is a gate rather than a phase. - **Production and handover**: Automated deployment, monitoring, a runbook, an architecture overview, and access transferred to whoever you name. ## How the price holds Software projects overrun routinely. Committing to a fixed price means volunteering to absorb that. So the question worth asking is what changed, not how confident we feel. Two things changed. Scoping runs through ScopeGen AI, which turns a client conversation into an estimated work breakdown, calibrated against what past projects took. And delivery is AI-First across the lifecycle, which compresses specification, implementation and test authoring. If our estimate is wrong on the scope you signed, we absorb it. That is what a fixed bid means. ## What it costs 200 to 400 story points for most products, settling to a committed figure once the scope is decomposed. A product with one primary journey and a light integration surface sits near the bottom. Several user types, payments, and three external systems sits near the top. If you cannot yet describe the product well enough to price it, start with a Product Definition Sprint. It costs 25 to 40 points and credits in full against this. - Points: 200 to 400, committed before work begins - Change orders priced before they start, with no penalty for changing your mind - 30 day warranty from your written acceptance of the production launch - Source code, designs and documentation become yours on full payment ========================================================================== # Paymentez > Electronic payments were 4% of revenue because the people transacting preferred cash. A UX rebuild moved daily transactions from 4,000 to 120,000. Source: https://www.koombea.com/work/paymentez/ --- Electronic payments were 4% of revenue. A UX rebuild moved daily transactions from 4,000 to 120,000. ## The problem Paymentez had a secure payment platform that its core users would not use. Electronic payments accounted for just 4% of revenue, because the people transacting, many of them children and retired women, preferred cash. Security was never the obstacle. The obstacle was that the flows presented every user with every option, and the relevant action was buried among the rest. ## What we built A redesigned payment gateway as a responsive web application in Ruby on Rails, with streamlined credit purchase flows for resellers, one-click purchasing, SMS payment, multilingual support, and business intelligence analytics. CPO Miguel Ramirez described the change: "Today's user experience is completely different than it was in the past. Now users are presented with only the actions and flows that are directly relevant to them." ## What happened - LAN house resellers grew from 85 to 4,700 in one year - Revenue from paying users went from $1.2M to $1.8M in six months, and $2.1M within a year - Conversion rates increased 42% in six months - Sales increased 30% in six months - Daily transactions grew from 4,000 to 120,000 ## Delivery notes Stack: Ruby on Rails, responsive web. Capabilities applied: Product Design, Integrations and Data. Delivered as a committed scope, estimated in story points and priced before work began. ========================================================================== # Security and Compliance > How we handle your code, your data and your access, plus the certifications and attestations we can put in writing. Source: https://www.koombea.com/company/security-and-compliance/ --- A regulated buyer will look for this page before they look at the work. Here is what we do, what we hold, and what we are willing to attest to. ## What we attest to On completion of a build we provide a written attestation covering the agreed security checks and any known critical or high-severity findings identified within that scope. That is a specific, bounded claim, which is what makes it worth having. We are careful about the wording. No engineering organization can honestly attest that software is free of unknown vulnerabilities, and any partner offering you that sentence is telling you something about their rigour. - Written attestation on completion, covering known vulnerabilities - IP assignment on full payment, automatic and in the contract - Software design and development unit appraised at CMMI-DEV/3 - Compliance QA available for HIPAA, PCI DSS and WCAG - A governance, risk and compliance service line, on its own pricing basis ## How we handle your access - **Least privilege**: Access is scoped to the engagement and removed when it ends. - **Credential hygiene**: Secrets managed in a vault, never in a repository or a ticket. - **Reviewed changes**: No unreviewed change reaches your production environment. - **Audit trail**: Who changed what, when, and against which approved item. - **Environment separation**: Development and production kept genuinely separate, including data. - **Data minimisation**: We ask for the least production data the work actually needs. ## Where the line is We prepare, implement, remediate and accompany. We do not issue your certificate, and no development partner can. An ISO/IEC 27001 certificate comes from an accredited certification body, a SOC 2 report from a licensed CPA firm, a PCI DSS Report on Compliance from a Qualified Security Assessor. You appoint them. The same boundary holds inside our own work. Someone who designs and runs your information security management system cannot then independently assess it. We say that up front, because the ambiguity is what creates the dispute later. If you need to know what Koombea itself holds, ask and we will answer in writing, naming what we have and what we do not. ## Compliance work is priced separately Governance, risk and compliance work never prices in story points, because the output is an assessment and an evidence trail rather than a feature. It prices four ways: a monthly retainer, a fixed fee per assessment, a scoped engagement for testing, or a phase price that follows the audit stages. You might need us to answer a security questionnaire, run a penetration test, review your HIPAA readiness, prepare you for SOC 2 Type II, or hold a vCISO retainer. Each one is a defined engagement with a defined deliverable. Ask in the Priority Sync. ========================================================================== # How AI Pods Pricing Compares > Three ways to buy software delivery, compared on what you actually buy, who carries the risk, and what you can forecast. Source: https://www.koombea.com/ai-pods/how-pricing-compares/ --- Time and materials, metered AI tooling, and a Koombea AI Pod are not the same purchase. The difference is who carries the risk when the estimate is wrong. ## What you are comparing | | Time and Materials | Metered AI Tooling | Koombea AI Pod | |---|---|---|---| | What you buy | Hours worked | Tokens, calls, or seats consumed | Delivered scope, measured in story points | | Who carries estimate risk | You do | You do, and the meter runs either way | We do, on the scope you signed | | What you can forecast | A burn rate, not an outcome | Neither reliably | A price and a scope, agreed upfront | | What overruns cost you | More invoiced hours | More metered usage | Nothing in points, on the agreed scope | | Quality accountability | Billed separately as QA | Yours to build and run | Generated tests and gates, inside the price | | Reporting | Timesheets | Usage dashboards | Points consumed against items shipped, weekly | | When it is the right choice | You own the backlog and want capacity | Your engineers want tooling, not delivery | You want an outcome at a known price | The metered column is not hypothetical. Publicly listed engineering firms now bill AI delivery in supervised tokens, against a monthly minimum with a variable fee above it. It is a real model, seriously meant. It counts what the work consumes. Ours counts what ships. ## The same work, three shapes ## The honest case for each Time and materials is the right purchase when you own the backlog and genuinely want capacity you direct. That is a real need, and it is why we still offer Staff Augmentation as a separate model rather than pretending one shape fits everyone. Metered AI tooling is the right purchase when you have engineers who want better tools. It is not a delivery model. The meter measures consumption, and consumption is not the same as shipped software. That distinction is no longer academic. Some of the largest firms in this industry now sell AI delivery by the token. It is a considered bet by serious people, and it deserves to be read as a real alternative rather than a straw man. It is also the opposite bet to ours. An AI Pod is the right purchase when you want a committed outcome and cost certainty before work begins. The tradeoff is that scope has to be defined well enough to price, which takes real work upfront. ## One prices the input. The other prices the output. Every pricing model answers one question: what are you counting? Hours count input. Tokens count input. Story points count output. That is the whole taxonomy, and everything else is packaging. Moving from hours to tokens looks like a revolution. It is not. It swaps one input meter for another. The unit got smaller, faster and cheaper, and the risk did not move an inch. An AI meter is still a meter. It just spins faster. Whoever counts the input carries none of the estimate risk. That is the part worth sitting with. If the work turns out to need three times the tokens, the meter simply reads higher. Nobody absorbs that. You do, the same way you did when it was hours. Counting output is a much harder promise, which is why almost nobody makes it. It means sizing the work before agreeing the price. It means eating the difference when the sizing is wrong. A vendor only offers that if they have changed something real about how the estimate gets made. Pricing in points does not make the tokens disappear, so here is where they go. You are never billed per AI call or per seat. Model tokens are covered up to a monthly allowance. Anything above it is passed through at cost, with no markup, within a model configuration you approve in advance, and reported every week. That pass-through arrives as its own line and never changes the price of a user story. You pay for output in points, and the input stays visible at what it actually costs. That is why AI-First is a commercial position and not a technical one. It does not make us cheaper. It makes the estimate accurate enough that committing to it is survivable, which is what lets us sell the outcome instead of the meter. - Hours count input. Tokens count input. Story points count output. - The question to ask any vendor: if this takes twice the work you expected, whose price changes? - On a meter, yours. On a point, ours. ## Why the economics work at all A fixed price on software delivery is usually a bet against yourself. Software projects overrun routinely, and a vendor who commits to a price is volunteering to absorb that. So the question worth asking is not whether we are confident. It is what we changed. Two things. AI-First delivery compresses the expensive parts: specification, boilerplate implementation, test authoring, and regression coverage. And we estimate with ScopeGen AI, our own scoping tool, which turns a client conversation into an estimated work breakdown and is calibrated against what each project actually took to deliver. That is the whole mechanism. It is not a discount, and it is not optimism about scope. ========================================================================== # Our Work > Selected engagements in health services, payments and lending, retail and commerce, and technology. Every figure here is one the client published. Source: https://www.koombea.com/work/ --- Eleven engagements by segment. If the client published a metric, we cite it. If they did not, we say so. ## Selected engagements ## What clients say on Clutch Same rule as the case studies. The scores come from clients, not from us. Clutch interviews each reviewer directly and publishes the result. Overall rating on Clutch: 4.9 out of 5. Across 24 verified reviews - Quality: 4.9 out of 5 - Schedule: 4.8 out of 5 - Cost: 4.7 out of 5 - Willing to Refer: 5.0 out of 5 ## References under NDA Not every client approves a public case study. We can give you references in your segment under NDA. Ask for them in a Priority Sync. ========================================================================== # AI Engineering > Building AI features that survive real users: evaluation, guardrails, cost control, and the retrieval work that makes answers correct. Source: https://www.koombea.com/capabilities/ai-engineering/ --- AI features are easy to prototype and hard to keep correct. The engineering is in evaluation, guardrails, retrieval quality, and cost that does not surprise you. ## The problem Almost any team can build an AI prototype that impresses people in a meeting. The difficulty starts afterwards, when real users send inputs nobody anticipated and the feature has to be right often enough to trust. That gap is an engineering problem with known parts. You need an evaluation set before you tune anything, so improvement is measured rather than felt. You need retrieval that returns the correct context, because most wrong answers are retrieval failures wearing a costume. You need guardrails on what the system is allowed to do. And you need to know what a thousand users will cost before you have them. We build all four as part of the feature rather than after the launch. An AI feature without an evaluation harness is not a feature, it is a hope. - An evaluation set built before tuning, so quality changes are measured - Retrieval quality treated as the primary lever on correctness - Guardrails on actions, not just on wording - Cost per operation modeled before scale, not discovered during it ## What this covers - **Applied AI features**: Assistants, extraction, classification, and search that work on your data. - **Evaluation harness**: A repeatable measure of correct, so tuning is engineering. - **Guardrails**: Constraints on what the system can do and what it can disclose. - **Cost and latency control**: Modeled per operation and tested at expected volume. - **Retrieval and grounding**: Getting the right context in front of the model, reliably. - **Production plumbing**: Queues, caching, fallbacks, and graceful degradation. ## From demo to something you can trust Feasibility, honestly: We establish whether the task is one current models are actually good at before anyone commits to a scope. Some are not, and finding that out in week one is the cheapest possible outcome. (Days) Build the evaluation set: A labelled set of real cases with expected outputs, agreed with you. This comes before any tuning, because otherwise improvement is a feeling rather than a measurement. (Before tuning) Retrieval and grounding: Get the right context in front of the model. Most wrong answers are retrieval failures, so this is where the accuracy actually comes from. (The main lever) Guardrails and fallbacks: Constrain what the system can do and disclose. Add provider fallbacks and modular adapters so one vendor's pricing change is not your outage. (Before launch) Cost and latency modeling: Measure cost per operation and test at the volume you expect, so a thousand users is a forecast rather than a surprise invoice. (Before scale) Monitor and re-evaluate: Model behavior drifts and providers deprecate. The evaluation set runs on a schedule, not once. (Ongoing) ## What drives the estimate AI features are the easiest thing to under-scope, because the prototype takes two days and everyone reasons from that. The build is priced from what it takes to make the thing correct often enough to trust, and almost none of that work is prompt writing. The dominant cost is your data. Retrieval quality is the main lever on correctness, and retrieval quality is mostly a function of whether the underlying content is clean, current, and chunked sensibly. A messy corpus is the single most common reason an AI feature costs double what a client expected. - The state of the data the answers must come from, which usually needs work before anything else does - How high the accuracy bar is, and who decides when it has been met - Whether the system only answers or is allowed to act, because actions need authorization and audit - The size of the evaluation set, which scales with how many ways the feature can be wrong - Whether a wrong answer is an inconvenience or a regulated event ## "The agent did it" is not an answer Every team that puts agents into its delivery process eventually hears that sentence, and it has no operational meaning. The person who delegated the work is accountable for what came back: the code, the tests, the document, the design. Naming the tool describes the toolchain, it does not transfer responsibility. We hold that line internally because you cannot buy a committed scope from a partner who can point at a model when something is wrong. Every artefact we hand you has a person who read it and accepted it. The second habit matters as much. When output comes back wrong, the instinct is to tell the agent to fix it. We do not do that first. We ask what gap in the specification allowed the misreading, and we fix the specification, because the same gap will produce the same class of error next week and the week after. That is the real shift. The work stops being writing the software and becomes designing the system in which the software gets written correctly. It is also why our estimates hold: the errors we fix are the ones that would have recurred. - Every artefact has a named human who reviewed and accepted it - A wrong output is treated as a specification defect first, an output defect second - Context is curated, because an agent will treat a superseded document as current - Superseded decisions are corrected at the source, not remembered selectively ## What we will talk you out of A chatbot on top of documentation nobody maintains. The bot will confidently repeat whatever is stale, and you will have bought an expensive way to distribute a wrong answer faster. An agent with write access to a production system on day one. Start read-only, prove the judgment, then grant actions one at a time behind authorization and an audit trail. Fine-tuning as a first move. It is occasionally the right answer and it is almost never the right first answer. Retrieval and prompt design get further for less, and they are reversible. Anything with no measurable definition of correct. If we cannot agree what a good output looks like, we cannot commit to a scope, and neither of us should pretend otherwise. ## Questions worth asking ### What happens when the model provider changes pricing or deprecates a model? This is why we build modular adapters and provider fallbacks rather than wiring one vendor's SDK through your application. Switching provider should be a configuration change and a re-run of the evaluation set, not a rebuild. ### How accurate will it be? Nobody can answer that before seeing your data, and a partner who quotes you a percentage upfront is guessing. We build the evaluation set first, measure where we start, and agree the bar we are committing to hit. ### Can you add AI to the product we already have? Yes, and that is the more common request. It is scoped as a feature against the existing system, with the same evaluation and guardrail work, because bolting it on does not make the correctness problem smaller. ### Is this priced differently from other engineering? The build is priced in story points like anything else. What is different is that we insist on the evaluation harness being in scope. An AI feature without one is not a feature, it is a hope, and we will not fixed-bid a hope. ## ScopeGen AI already runs this workflow AI-First delivery is also how we work internally. ScopeGen AI turns a client conversation into an estimated work breakdown, which is why we can price scope before it is built. ========================================================================== # Tambora > Tambora is the QA management platform Koombea built and maintains. Test case design from a written requirement, coverage per release, and an MCP server that answers coverage questions inside the editor. Source: https://www.koombea.com/products/tambora/ --- Tambora is the QA management platform we built and maintain ourselves. It is where testing gets organized, documented, and tracked, and its test case assistant turns a written requirement into structured cases in minutes. ## What it is Most QA effort lives in spreadsheets and loose documents. That holds up until someone asks the one question that matters. What did we actually test before that release, and what did we not. Tambora answers it. Cases are organized into modules and suites, executed against a release, and reported on. Coverage stops being a claim someone makes in a status meeting. It becomes a number attached to a named run. It exists because we outgrew the alternative. As the delivery teams grew, so did the number of projects a single quality standard had to hold across, and general-purpose trackers gave us no structure to hold it with. So the internal product team designed, built, and tested Tambora for the two people who use it most: the engineer writing the cases and the manager who has to answer for them. It has since spread across the whole operations team. We built it and we run it. AI has been in it for over a year. It is not a license we resell, and it is not a tracker with a chat box bolted on. It is what our own quality practice depends on. - Modules and suites, with hierarchy, so a large product stays navigable - Cases documenting preconditions, steps, and expected results - Execution with real statuses, including passed, failed, blocked, and retested - Coverage and execution progress visible per project rather than per person's memory ## What it changed Three figures, all measured against how we worked before it existed. - Less time designing test cases: Measured against our own before and after, not an analyst's benchmark - From a written requirement to structured cases: The same work used to run to hours, so it was the first thing cut - Coverage attached to a named release: Rather than to somebody's recollection in a status meeting ## The part that changed the economics The test case assistant runs on our own agents, defaulting to the Claude API, with dynamic model selection so an engineer can switch the model mid-session to suit the work. You give it a requirement written in plain language. It returns structured cases: the happy path, the negative cases, and the edge cases that are the ones worth writing down. It fills in contextual test data as it goes, down to the card numbers a payments flow needs. Nothing it produces is read-only. Every generated case is editable, categorized, prioritized, and linked to its Jira ticket before it is saved, which is the whole difference between a chat box and a tool. Against our own before and after, it cuts test case design time by 50 to 75%. That is our figure, not an analyst's. It is also why the coverage bar on our engagements sits where it does. Thorough testing stopped being the first thing cut when a date moves, because it stopped being the expensive part. The second piece matters most to engineers. Tambora runs its own MCP server. An engineer or designer can ask what the coverage is for a run, a tag, a severity, or an acceptance criterion, from inside their editor. No context switch. No asking someone in another channel. - Structured cases generated from a requirement written in plain language - Positive, negative, and edge cases, with contextual test data filled in - Every case editable, categorized, and linked to a ticket before it is saved - 50 to 75% less time designing cases, measured against our own baseline - An MCP server that answers coverage questions inside the editor - Coverage queried by test run, tag, severity, or acceptance criterion ## From a requirement to an executed case Write the requirement: An engineer states what the feature is meant to do, in plain language, inside the module it belongs to. (Minutes, not a workshop) The assistant proposes cases: Positive, negative, and edge cases come back structured, with preconditions, steps, expected results, and contextual test data already filled in. (Seconds) The engineer decides: Cases are edited, prioritized, assigned to a module, and linked to their Jira ticket. Judgment stays with the person who has it. (The assistant proposes, it does not approve) Execute against a run: Cases are stored, executed, and marked passed, failed, blocked, or retested against a named test run tied to a release. (Coverage becomes a fact) Managers see the picture: Coverage, execution progress, contribution, and history, per project and per release, without asking anyone to assemble it. (Dashboards, not a status call) "We didn't just want AI that outputs text. We needed usable test cases directly inside the system. That's what we built." Felipe Guerrero, Director of Quality, Koombea ## What is in it - **Modules and suites**: Cases organized by module and submodule, with suites and sub-suites for products too large to hold in one list. - **Test Run**: Plan and execute everything QA needs to do before a release, so coverage of a feature is a fact attached to a run. - **Test case assistant**: Built on our own agents, defaulting to the Claude API. A written requirement in, structured cases out. - **Dynamic model selection**: The model is a setting, not an architecture decision. An engineer picks the one that suits the session, and sessions stream back over an event-driven channel rather than blocking on a reload. - **Iterators**: Document a scenario once, then declare how many times it runs: per browser, per document type, per device, including combinations. - **Metrics and dashboards**: Coverage, execution progress, and contribution, per project rather than per anecdote. - **Roles and permissions**: Separate access for administrators, testers, engineers, and read-only users. - **Jira integration**: Cases and runs link to their tickets and epics, so traceability survives contact with the backlog. - **Documents**: A central home for operational records: accessibility conformance reports, release plans and protocols, transition plans. - **Tambora MCP**: Coverage exposed to the editor, so the question gets answered where the work is happening. ## Before Tambora, and after it | | Before | With Tambora | |---|---|---| | Designing a test case | Hours of manual writing, per feature, by whoever had the context. | A requirement in plain language, structured cases back in seconds, 50 to 75% less design time. | | Where cases live | Spreadsheets and documents, named by whoever made them. | Modules, suites, and sub-suites, navigable on a product too large to hold in one list. | | Test data | Invented on the spot, or copied from the last time. | Auto-filled from context, down to the card numbers a payments flow needs. | | Answering "what did we test" | A recollection, assembled by hand ahead of the meeting. | A coverage figure attached to a named run, queryable by tag, severity, or acceptance criterion. | | Where an engineer works | Tracker, spreadsheet, ticket, chat. Four tools, one question. | The editor. Tambora's MCP server answers coverage there. | | Manager visibility | Ask each person, then total it up. | Coverage, execution progress, contribution, and history, per project. | | Operational records | Scattered, and gone when the person who wrote them moves on. | Conformance reports, release protocols, and transition plans in one documents module. | ## Why this matters on your engagement ### During the build — Coverage you can see, not coverage you are told about. Cases link to tickets and execute against a named run. So the coverage figure at phase acceptance points at specific scenarios. When an acceptance criterion has nothing behind it, that shows up before the phase closes. Not after a customer finds it. - Every acceptance criterion traceable to the scenarios that prove it - Coverage reported against a release, not as a general assurance - Gaps surfaced while there is still time to close them ### At handover — The record outlives the people who made it. Handovers fail on undocumented knowledge. The documents module keeps accessibility conformance reports, release protocols, and transition plans in one place. The case library does something quieter and more useful. It describes, in readable form, how the product is meant to behave. - Operational records kept where the next team will look for them - A test library that documents intended behavior, not just outcomes - Continuity when responsibility moves between teams Tambora is internal tooling rather than something you license. What reaches you is the output: the coverage numbers, the traceability, and the records that make a handover survivable. ## Where it is going Two things are in progress. A master test plan that groups the cases and runs for a feature under one lifecycle, from draft through ready, in progress, completed, validating, and approved, so a feature can be traced from its specification to its final validation in one place. The second is a knowledge library: an assistant trained on how we actually run quality here, so "how should we test a multi-tenant application" or "what belongs in a test plan for this feature" gets a Koombea answer rather than a generic one. The documents module is already going the same way. It holds the operational records a delivery organization is judged on, including accessibility conformance reports, release plans and protocols, and transition plans, which is what makes it possible for someone to take leave without the engagement holding its breath. Both follow the same direction of travel. Tambora started as somewhere to keep test cases and is turning into the place quality strategy is decided. ## Quality runs on software we built A partner renting an off-the-shelf test tool is making a claim about testing. A partner that built its own, put AI into it over a year ago, and runs its client work on it is making a different one. ========================================================================== # Legacy Assessment > A scoped AI Pod that answers what to do with an aging system, with a costed roadmap, before you commit a budget to the wrong option. 30 to 50 points. Source: https://www.koombea.com/ai-pods/catalog/legacy-assessment/ --- A short engagement that answers the question with evidence and a costed roadmap, so the largest decision in your technology budget stops being an argument between confident people. ## The problem Everyone in the building already has an opinion about the old system. The engineers who maintain it want it gone. The people who depend on it want it untouched. Whoever signs the cheque has to choose between two groups of confident colleagues and no numbers. That decision is usually worth seven figures over three years. It gets made on instinct anyway, because the analysis feels like a delay. It is not a delay. It is the cheapest part of the whole program. We measure what it costs you to change the system now. Then we cost each alternative. Then we say which one we would pick, and why. - A recommendation, not three options and a shrug - Costed in story points, so it converts directly into a budget - Written to be read by the person approving it, not only by engineers ## What this Pod ships - **Cost of change, measured**: What a typical change costs today in time and risk, established from the repository and the ticket history rather than from anecdote. - **Architecture and dependency map**: What the system is made of, what it talks to, and which parts can move independently of the rest. - **Risk register**: Unsupported runtimes, absent tests, single points of failure, and the compliance exposure each one carries. - **A costed recommendation**: Save, rewrite or replace, with the story point cost of each path and the sequence we would run. ## What an assessment hands you ## Why we rarely recommend a rewrite A rewrite replaces a system you understand with one you do not. It also asks the business to stop receiving value while it happens. Sometimes that is the right call. Far more often the economics favor carving the system up and moving it one piece at a time. We tell you which case you are in. Sometimes the system is fine and the real problem is the deployment process. If so, that is what the document says, and it cost you 30 points to find out. ## What it costs 30 to 50 story points depending on how many systems are in scope and how much of the history is documented. Quoted before work starts. If you go on to run the recommended work with us, the assessment credits in full against the first phase, provided the work starts within 90 days. The window matches the one on banked points. - Points: 30 to 50, agreed before work begins - Timeline: two to three weeks - Credits in full against the modernization work if you start within 90 days - The roadmap is yours, whoever ends up delivering it ========================================================================== # Fashioned Health > iOS and Android telehealth apps on HIPAA-compliant infrastructure, with video consultation, patient-provider messaging and test result visualisation. Source: https://www.koombea.com/work/fashioned-health/ --- A HIPAA-compliant telehealth product built to reduce unequal access to care. ## The problem Founder Thomas Caraballo, a healthcare professional, started from the obstacles patients face reaching care at all. The company's stated aim is to reduce unequal access to healthcare and improve patients' health span. A product with that aim has to carry HIPAA obligations from the first commit, and it has to make clinical information legible to people without clinical training. ## What we built iOS and Android apps on HIPAA-compliant infrastructure, with test result visualisation to help patients understand their own exam results, health goal setting, integrated patient-provider messaging, and video consultation. Payments run through Stripe under PCI compliance, messaging through Sendbird, and video through Twilio. ## What happened The source case study publishes no adoption, retention or clinical outcome figures, so none appear here. - HIPAA-compliant infrastructure with data protection protocols in place - PCI-compliant payment handling - Indigo Design Award recognition for the app - The app has helped many users navigate the healthcare system ## Delivery notes Stack: Ruby on Rails, Swift, Kotlin, Stripe, Sendbird, Twilio. Capabilities applied: Governance, Risk and Compliance, Product Design. Delivered as a committed scope, estimated in story points and priced before work began. ========================================================================== # Partners and Certifications > AWS Partner Network, Stripe Verified Partner, Shopify Plus Partner, CMMI DEV/3, ISTQB and Scrum Alliance certifications. Source: https://www.koombea.com/company/partners/ --- A partner badge is only worth showing if it gives you something. These give us access, escalation paths, and in one case an independent appraisal of how we deliver. ## Partnerships and certifications ## What each one gets you - **AWS Partner Network**: Architecture review and a support path when infrastructure is the constraint. - **Stripe Verified Partner**: Verified integration practice for payments, including PCI scope reduction. - **Shopify Plus Partner**: Plus-tier access for commerce builds, replatforms and StorefrontOS. - **CMMI-DEV/3**: An independent appraisal of our development process, not a self-assessment. - **ISTQB and CAT**: Certified testers, which matters when quality is a contractual gate. - **Scrum Alliance**: Certified ScrumMasters, for the clients who still run Scrum internally. ## Recognition we did not pay for Our work has taken Indigo Design Awards across Luna, Nab, Fashioned Health, FlightLogger and our own website, including Gold for UX, Interface and Navigation. Clutch has named us among the top developers in Latin America, and Inc. named Koombea a Power Partner. ## Partner with us on delivery The partnerships above are ones we hold. This is the other direction: a program for people who want to send work to us, or who need delivery capacity behind work they have already won. There are two models and they are genuinely different, so it is worth knowing which one you are asking about before you fill in the form. ## Two Models, Not a Spectrum ### Referral — You make the introduction. For anyone, company or individual, who knows a business that needs software built. You make the introduction and step back. We run the relationship from there, and you get a referral commission if the deal closes. - No delivery involvement and no account management on your side - Commission on close, with the terms agreed before you introduce anyone - We tell you plainly if it is not a fit, rather than sitting on it ### Strategic — You keep the client, we build. For agencies and software companies with more demand than capacity, or with work outside what their team does. You own the client relationship and the commercial terms. We deliver against a committed scope behind you, at whatever level of visibility you want. - You stay the client's point of contact throughout - Scope committed and priced in story points, so your own quote holds - White-labelled or named, whichever the relationship needs - CMMI-DEV/3 appraised process behind work that carries your name Either way the commercial basis is the same as any other engagement. Scope is defined upfront and priced in story points, so what you quote your client and what you owe us are both known before work starts. ## How a partnership starts The first conversation is about the specific project, not about the program. We need to know what has to be built, what it has to integrate with, and what has already been promised to whom. From there it is the same scoping process as any engagement. Scope goes into a Work Breakdown Structure, gets priced in story points, and both sides agree it before anything is committed. That matters more in a partnership than anywhere else, because you may have already quoted your client and a price that moves later is your problem, not ours. - One call about the project, not a program pitch - A Work Breakdown Structure and a story point price before commitment - Delivery in two-week cycles, with whatever reporting you need to pass on - An honest answer when the work is a poor fit for this model ## Interested in partnering with us? Tell us which model fits and what the work looks like. If you are not sure which one, describe the client situation and we will tell you. "2 years ago when I started working with Koombea, I would have just used the term client, but now I think of them as a real business partner." Ashkán Zandieh, CEO, Sonoture ========================================================================== # Retail and Commerce Software Development > Commerce platforms, native mobile storefronts and omnichannel operations, including StorefrontOS for Shopify merchants. Source: https://www.koombea.com/industries/retail-and-commerce/ --- The storefront is the visible part. What determines whether it works is inventory, pricing, fulfilment, and the systems that have to agree about all three. ## What makes this different Retail projects are usually described as a website and delivered as an integration project. The catalog lives in one system, prices in another, stock in a third, and the store is only as trustworthy as the agreement between them. We treat the operations layer as the real work: unified order and inventory management, point-of-sale and accounting integration, and pricing rules that can vary by region without becoming unmaintainable. We are a Shopify Plus Partner, so the store itself is built with Plus-tier access rather than around its limits, and for merchants who want a native app, StorefrontOS removes most of that build. The commerce foundation is already there, so the engineering goes into your brand rather than into reinventing a cart. - Unified inventory and order management across channels - POS, ERP and accounting integration with reconciliation - Regional and segmented pricing that stays maintainable - Native mobile commerce in 2 to 3 weeks through StorefrontOS ## What we build here - **Commerce platforms**: Shopify and Shopify Plus builds, including replatforms. A Plus Partner since 2018. - **Native storefronts**: Owned mobile channels on StorefrontOS, not a wrapper around a website. - **Omnichannel operations**: Buy online, pick up in store, and the inventory truth behind it. - **Catalog and data**: Master data management so product information stays correct. - **Merchandising analytics**: Numbers that inform buying, not just traffic charts. - **Peak readiness**: Verified against your actual seasonal burst, before it arrives. ## A Shopify Plus Partner since 2018 Plus Partner status is granted by Shopify rather than claimed, and Koombea has held it since 2018. It gives Plus-tier access for builds and replatforms, checkout extensibility that the standard platform does not permit, and an escalation path when the blocker turns out to be Shopify rather than the code. Higher API limits are what make real-time ERP and OMS sync viable at volume. Company accounts and price lists carry B2B without a second storefront to maintain. And Shopify keeps PCI scope and flash-sale traffic, which are two things you would otherwise own. - Replatforms from Magento, WooCommerce and custom carts, with order history intact - Checkout extensibility for B2B terms, custom validation and payment routing - Higher API limits, so ERP and OMS integration holds up at peak - Headless storefronts where the theme layer is the constraint ## StorefrontOS, the native storefront For Shopify merchants who want an owned mobile channel, StorefrontOS ships the commerce foundation already built and tested: cart, checkout hand-off, authentication, order history, and product variants. Launch is 2 to 3 weeks from kickoff, on a fixed scope and one price. The native clients read the Shopify Storefront API directly, so there is no parallel commerce backend and no second copy of the catalog to reconcile. Shopify stays the source of truth for products, inventory, pricing, and customers, and your team's workflow does not change. ### What ships with it - Discover and browse: CMS-controlled home modules, product grids, filters, search, and variant previews. - Cart and checkout: A native cart handing off to Shopify checkout, including Shop Pay and Apple Pay. - Accounts and retention: Customer profiles, order history, and a push channel you own. - Operations: Real-time Shopify sync, multi-market support, and analytics. ## Proof Do It Center's replatform cut bounce rate by 90%, reached an NPS of 70, and saw average purchase run 5X higher than in physical stores, with 75% of online transactions collected in store. ## Where to go next If you are on Shopify and want an owned mobile channel, start with StorefrontOS. If the operations layer is the problem, start with the case studies. - StorefrontOS: Your Shopify store as a native app in 2 to 3 weeks, with Shopify still the source of truth - Shopify Plus Agency: Plus builds and replatforms, and what Partner status since 2018 actually gets you - Do It Center: Case study: bounce rate down 90%, NPS of 70, and 75% of online orders collected in store - Jamar: Case study: PDF catalogs to Shopify Plus, with regional pricing preserved rather than flattened ========================================================================== # Quality Engineering > Software testing services built into delivery. Tests generated with the spec, enforced on every merge, plus load and accessibility checks. Source: https://www.koombea.com/capabilities/quality-engineering/ --- If software testing is something that happens after the build, it is the first thing cut when the date slips. We make it the condition of merging instead. ## The problem The traditional shape puts QA at the end, which guarantees two things. Defects are found at their most expensive moment, and the whole activity becomes negotiable the instant a deadline gets close. We invert it. The tests come from the spec, and they are written before the build rather than after it. A test written from the spec asks whether the implementation does what was required. A test written from the finished implementation only asks whether the implementation does what it does. Those tests run as a gate on every merge, so work that does not pass does not merge, which takes the decision out of anyone's hands at 6pm on a Friday. The result is not zero defects, because nothing produces zero defects. It is that the defects you get are the interesting kind, found early, rather than a regression in a feature that worked last month. - Tests written from the spec, before the build, not from the finished code - A second, independent check that the code matches the spec, not just itself - Automated review and quality gates on every merge - Regression suites that grow with the product instead of rotting ## The failure mode AI-First delivery has This is the part most AI development pitches leave out, and it is the reason our QA discipline looks different from a traditional one. When an engineer asks an agent to build a feature, the agent will happily produce the implementation and the tests in the same pass, from the same reading of the spec. If that reading was wrong, the implementation is wrong and the tests pass anyway. Nothing in the pipeline objects. The code is confidently, verifiably wrong against a standard it wrote for itself. That is not a bug in the model. It is a structural property of any system that generates the work and the check together. Speed makes it worse, because the wrong thing gets built on top of before anyone re-reads the requirement. So we break the loop deliberately. The scenarios are defined from the spec before implementation starts, by someone other than whoever drives the build. After the build, a separate set of checks verifies the spec requirements the build's own tests did not cover, written by a different person for a different purpose. Two authors, two intents, and a real chance of catching the misreading. - Scenarios defined from the spec before the build, not derived from the finished code - A separate compliance pass written by someone other than the build author - Particular attention where an agent plausibly diverges: data scoping, authorization, default state, negative paths - Authorization checked at the API and data layer, not only where the UI hides the button ## Who owns what, and when The judgment that cannot be automated is deciding what must be proven and where an agent is likely to go wrong. That is a different job from writing the tests, so it belongs to a different person. | | Defined before the build | Built and checked after | |---|---|---| | What must be proven | The behavior contract: happy path, validation rules, edge cases, accessibility | Implemented as tests at whichever layer proves it most cheaply | | How serious a failure is | A severity per scenario, agreed upfront | What gets fixed first when something goes red | | When it runs | Smoke, full, or regression, decided per scenario | Wired into the pipeline as a gate | | Where an agent might diverge | Noted per scenario, in advance | Targeted by an independent compliance check after the build | | Which stack layer | Deliberately not decided here | The engineer's call at build time: unit, component, integration, end to end, or visual | Automation is no longer the expensive part, so a plan that stops at "we will write tests" is not a plan. Deciding what to prove is the work. ## What this covers - **Automated regression**: A suite that runs on every change and is maintained as part of the work. - **Performance and load**: Stress testing and scalability validation against real expectations. - **Device and hardware QA**: Bluetooth, IoT, payment terminals, and NFC on real hardware. - **Security testing**: Vulnerability assessment and penetration testing by specialists. - **Accessibility**: WCAG verification treated as a requirement, not a retrofit. - **Quality reporting**: What is covered, what is not, and what changed this cycle. ## The pyramid, and what gates on it Test strategy here is shaped like a pyramid, which is unfashionable to say and still correct. Many fast unit tests, fewer integration tests where components meet, and a thin layer of end-to-end tests covering the journeys that would cost you money if they broke. The inversion is what goes wrong elsewhere. A suite that is mostly end-to-end tests is slow, flaky, and eventually ignored, and an ignored suite is worse than no suite because it produces false confidence. So we keep the expensive layer thin on purpose. All of it runs as a gate. Linting, unit, integration and end-to-end run in the pipeline, and work that does not pass does not merge. On phase acceptance the coverage thresholds are explicit numbers rather than a promise: at least 70% unit and at least 50% integration on the code we wrote, measured against our code rather than inflated with vendored libraries. - Unit, integration, then a deliberately thin end-to-end layer - Linting and every test tier running as a merge gate, not a nightly report - At least 70% unit and 50% integration coverage on Koombea-authored code at phase acceptance - Coverage measured on our code, never padded with third-party libraries - A higher bar on the paths that carry risk: authentication, authorization, payments - No P1 or P2 defect open at handoff, which is a hard gate rather than a target ## A gate that does not fail the build is decoration Every pipeline we run enforces the same baseline before anything merges: linting at zero errors rather than zero blocking errors, type checking with no suppressions, the unit suite passing, a coverage floor, static analysis, and a dependency scan for known vulnerabilities. The rule that matters is that the gate has to be able to fail. A check that is installed but not enforced tells you nothing and trains everyone to ignore the red. If we ever disable one, the reason and the date it goes back on are written down. We also check the artefact rather than the exit code. A test command that runs zero tests exits successfully, and a pipeline reporting green having executed nothing is worse than no pipeline, because it manufactures confidence. So the gates assert that the output exists and has the shape it should, not merely that a command returned zero. - Lint, types, unit suite, coverage floor, static analysis, dependency scan - Every gate blocks the merge, or it is not a gate - Test runs assert a plausible test count, so a silent zero cannot pass as green - A disabled gate carries a written reason and a date to restore it ## The toolkit, named - **Browser and mobile automation**: Selenium and Appium for cross-browser and real-device coverage. - **End-to-end**: Cypress for the journeys whose failure would cost you money. - **Load and performance**: JMeter against your expected volume and burst pattern, not a round number. - **Traceability**: BDD with Cucumber and Gherkin where a requirement has to be provably tested. - **AI-First test design**: Tests generated from the same spec that drives implementation, then reviewed. - **Our own test management**: Built and operated in house rather than rented, and it is why the reporting is specific. ## What drives the estimate Quality is not a separate line item here, because tests are generated from the spec that drives the build. So the question is not what QA costs. It is what raises the coverage bar, and that is worth knowing before you choose a scope. - Regulated data or money movement, which raises the required coverage rather than the feature count - The device and browser matrix you actually need to support, which is usually smaller than the one requested - Physical hardware in scope: Bluetooth, NFC, payment terminals and IoT need real devices, not simulators - Whether an accessibility conformance level has to be verified and evidenced - Role and permission combinations, which multiply test surface faster than anything else ## Questions worth asking ### Can we just skip the tests to hit a date? No, and this is the one place we are inflexible. The tests are how a fixed bid is survivable for us and how the warranty means anything for you. If a date is genuinely immovable we cut scope, which is a decision you get to make, rather than cutting verification, which would be a decision we made for you quietly. ### We have no tests at all. Where do you start? With tests against current behavior on the paths that matter, before changing anything. That is a safety net rather than an ideal suite, and it is what makes the first changes safe. Building coverage backwards across a whole legacy codebase is rarely worth it. ### Is manual testing gone? No. Exploratory testing finds the things nobody thought to specify, and no automated suite replaces someone competent trying to break a product on purpose. What is gone is manual regression testing as the primary safety mechanism. ### Does 70% coverage mean 70% of bugs are caught? It does not, and anyone implying otherwise is selling you a number. Coverage measures which lines ran, not whether the assertions were meaningful. It is a floor that prevents the obvious failure, which is why we pair it with acceptance criteria and edge cases that have to pass. ### Who runs penetration testing? Specialists, under the governance practice, on a retainer or fixed fee. It is deliberately not part of a story-point build, because an audit opinion is not a feature. ## Credentials behind the quality gates Our teams hold ISTQB and Certified Agile Tester credentials, and Koombea's software design and development unit has been appraised at CMMI-DEV/3. ========================================================================== # Blog Authors > Who writes the Koombea blog, what each person actually works on, how many posts they have in the archive, and what a byline on a post commits us to. Source: https://www.koombea.com/company/authors/ --- The archive holds 1,069 posts. 975 of them carry a byline, and the people below wrote 561 of those. Every one of them now says so on the post itself. ## What a byline commits us to A byline is not a credential. It is a statement about who is accountable for what a post says. That distinction matters most on the posts that describe how we build software. A claim about specifications, testing, or delivery is only worth reading if a named person can be held to it. So the name on a post is the person answerable for it, and the same field that prints it also drives the structured data search engines and AI assistants read. One field, one source. A name cannot say one thing to a reader and something else to a machine. - The name on the post is who is accountable for its claims - Roles come from the same list published on our about page - A post with no named author publishes under Koombea, not under a person ## Who writes here Focus areas below are counted from the posts each person actually wrote, not from a job description. ## Guests and corrections Twenty three posts carry "Guest Author". Those were written by people outside Koombea, and where we can attribute one properly we will. The archive goes back to 2015 and parts of it are old enough to be wrong. If a post has your name on it and should not, or is missing your name and should have it, tell us and we will correct it. ========================================================================== # FlightLogger > Real-time flight tracking across 1,500 airlines and 30,000 airports, on iOS, Android and Apple Watch. Gold for UX at the Indigo Awards. Source: https://www.koombea.com/work/flightlogger/ --- Real-time flight tracking across 1,500 airlines and 30,000 airports, with Gold for UX at the Indigo Awards. ## The problem The brief sounds simple: show a flight itinerary as a timeline. The difficulty is everything that complicates a timeline, including time zones, flights that cross midnight, multi-leg journeys, and changes that arrive after the passenger has stopped checking. Getting an edge case wrong in this product does not produce a cosmetic bug. It produces a missed flight. ## What we built iOS and Android apps with real-time tracking, terminal, gate and baggage claim notifications, timeline itinerary visualisation, flight sharing, automatic forwarding by email, calendar sync, and aircraft location mapping. Also Apple Watch support, Siri Shortcuts, light and dark themes, and offline access, drawing on third-party data providers and distributed flight models. ## What happened - Tracks over 1,500 airlines with worldwide coverage of over 30,000 airports - Tens of thousands of downloads and tens of thousands of monthly active users - Hundreds of active paid subscriptions - Indigo Design Award: Gold in UX, Interface and Navigation, 2019 - Predominantly five-star user reviews ## Delivery notes Stack: Native iOS and Android, Apple Watch, third-party aviation data. Capabilities applied: Product Engineering, Product Design. Delivered as a committed scope, estimated in story points and priced before work began. ========================================================================== # How AI Pods Compare to Vibe Coding > Vibe coding is genuinely excellent at reaching a working demo. Production software is a verification problem. What sits in that gap, and who closes it. Source: https://www.koombea.com/ai-pods/vs-vibe-coding/ --- The tools are good and getting better, and that is not the argument. The argument is what happens after other people start depending on what you built. ## Software used to look as unfinished as it was For thirty years an unfinished product looked unfinished. Placeholder text, a broken link, a login button that did nothing. You could tell how far along something was by looking at it, and so could everyone else in the room. That signal is gone. A founder can describe a product on Friday and open a real URL on Monday: working sign-up, a dashboard with live data, Stripe taking test payments, a domain with a certificate on it. It looks finished because in every way a screen is capable of showing, it is finished. What a screen cannot show is authorization, tenant isolation, rate limits, secrets handling, backups, migrations, audit trails, observability, or what happens the first time an integration times out halfway through a transaction. None of that has a visual state. It is either there or it is not, and the demo looks identical either way. That is the real shape of the prototype-to-production gap. Not that it is large. That it is invisible, and invisible specifically to the person who has to decide whether to launch. ## What the promise says and what it leaves out | | Vibe coding says | The question it leaves open | An AI Pod answers | |---|---|---|---| | Speed | Build it in an afternoon. | Can it survive three years of changes? | AI velocity, with an architecture someone owns. | | Requirements | Just describe what you want. | What did you not know to describe? | Scoping that surfaces the requirements you did not ask for. | | Correctness | The AI fixes its own bugs. | Who tells you when the fix is wrong? | Human review and generated tests gate every merge. | | Architecture | The AI writes the code. | Who decides how the system is shaped? | Humans set architecture. AI accelerates implementation. | | Deployment | Ship it with one click. | Is it safe to ship? | Production gates, not a button. | | Change | Every change is cheap. | What does a regression cost? | Tests, observability, and controlled releases. | | Team | You do not need developers. | Who is accountable once customers depend on it? | A named Pod, accountable for the outcome. | | Ownership | You own the output. | Does anyone understand it? | Source, architecture map, and decision log at handoff. | Every line in the first column is true. These tools do what they say, and the claims are not the problem. The middle column is. ## Generation is solved. Verification is not. The interesting thing about AI code generation is not that it works. It is how completely it works. Veracode's 2026 GenAI Code Security Report tested more than a hundred models against a fixed set of coding tasks and found that modern models now produce syntactically correct code close to a hundred percent of the time. Whatever the argument about AI and software still is, it is no longer an argument about whether the code compiles. The same testing put the security pass rate at 56 percent, essentially unchanged from the year before. Roughly forty-four of every hundred code-generation tasks introduced a known, risky vulnerability. Correctness went to near-total. Safety did not move. Those two numbers describe a system that has become excellent at producing code that runs, and has not become better at producing code you should trust. The distance between them is not a gap in the models. It is the part of software engineering that was never about typing. Vibe coding optimizes for creation, and by that measure it is the best thing anyone has built. Production software is not primarily a creation problem. It is a verification problem: proving that what was built does what was intended, does nothing that was not intended, and keeps doing both while people change it. That work has a name. It is engineering, and it did not stop being necessary when generation got cheap. Cheap generation arguably makes it more necessary, because there is now far more code per hour arriving to be verified. - Syntax correctness: near total. Security pass rate: 56 percent. - The models did not get less safe. They got much faster at everything else. - More code per hour means more to verify per hour, not less. ## One of these got cheaper ## Where the gap opens ### The prototype cliff — The interface is finished, so the product must be finished. Auth, permissions, backups, rate limits, logging, and deployment architecture have no screen. A polished front end is not evidence that any of them exist. It gets read as evidence anyway, because for thirty years it was. ### Functional is not safe — The code runs and looks right. That is a weak signal. Authorization checks that live in the browser, admin roles a user can edit, service keys shipped to the client. All of it renders correctly. None of it holds. Neither the founder nor the agent reliably sees the difference, because there is nothing to see. ### Context decay — The agent forgets the system it is working inside. As pages, models, auth, and payments accumulate, an agent starts duplicating components, editing unrelated files, and introducing patterns that contradict last month's. Every change is locally reasonable and globally corrosive. ### The debugging spiral — Fast generation can produce slow recovery. A bug appears. The fix touches more code. That produces two new failures. Teams describe losing weeks and serious credit budgets inside this loop, on codebases nobody can read well enough to break out of it. ### Architecture by accident — The easiest implementation gets built first, every time. Prompt-first development starts at implementation. Nothing forces a decision about system boundaries, data ownership, or trust boundaries, so the architecture becomes whatever the sequence of prompts happened to accumulate. ### Nobody owns it — You know what it does. Nobody knows why it does it that way. Software is not an output. It is an asset somebody has to operate, extend, and answer for over years. That takes people who can explain the decisions, and generated code tends to arrive with the decisions stripped out. ## This is measurable, not theoretical In May 2026 the security firm RedAccess scanned roughly 380,000 publicly reachable applications built on Lovable, Base44, Replit, and Netlify. About 5,000 of them were exposing sensitive corporate or personal data to anyone who found the URL. The examples are ordinary rather than exotic: internal financials from a bank, a shipping company's vessel schedules, patient conversations at a healthcare provider, customer service logs from a retailer. Nothing was breached. The data was simply reachable, because several of these platforms default new projects to public and the person building was not a developer and had no particular reason to know. The platforms disputed parts of the finding, and the dispute is fair. None of these tools forces anyone to ship an open database, and experienced engineers use them every day without doing so. The number is not an indictment of the tools. It is a measurement of what happens when software gets built with nobody in the room whose job is to ask what is exposed. ## When vibe coding is the right answer Often. It is the fastest way to find out whether an idea is worth real money before spending real money on it. It is the right tool for an internal utility with five users who all sit near each other, and for the throwaway prototype that exists to settle an argument in a meeting. It is also, increasingly, the right tool inside a professional engineering process. We use these tools. An AI Pod is AI-First across scoping, specification, implementation, and test generation, and that compression is the only reason we can commit to a price instead of billing you for the discovery. So this is not an argument against vibe coding. The problem was never that AI writes the code. The problem is removing software engineering from software development and expecting the result to carry weight. Keep the velocity. Put the engineering back around it. ## What an AI Pod puts around it An AI Pod is a lean delivery unit that ships production software against a committed scope, priced in story points, in two-week cycles. The AI is the same AI. What changes is everything surrounding it. Architecture gets decided by people before implementation starts, rather than inferred from the order the prompts arrived in. Generated tests and automated review gate every merge. Work reaches production through gates rather than a button. And at the end you own the source, the architecture map, and the reasoning, because you have to operate this for years after we stop. - Humans set architecture. AI accelerates implementation - Generated tests and automated review gate every merge - A price agreed before work begins, with the estimate risk on us - Your IP on full payment, with the decisions documented ## Questions worth asking ### We already built something in Lovable. Is it wasted? Usually not. A working prototype is a specification that runs, which is a far better starting point than a document. It tells us what you actually want with a precision that requirements gathering rarely reaches. What it does not tell us is what has to change underneath, and assessing that is the first thing we do. ### Do you rewrite it or harden it? It depends what is there, and we will tell you which one honestly. Interface work and product logic frequently survive. Data models, authorization, and anything touching money or personal data are the most likely to need rebuilding, because those are where a locally reasonable shortcut is hardest to unwind later. ### Do AI Pods use the same AI tools? Yes, and more of them. AI-First runs across scoping, specification, implementation, test generation, and deployment. The difference is not the tooling. It is that a named team of engineers is accountable for the output and every merge passes a gate before it reaches your users. ### How do I tell how production-ready my app actually is? Ask what happens in each of these cases: a user edits their own role, a request arrives a thousand times a second, the database is restored to yesterday, an integration times out mid-transaction, and an auditor asks who accessed a record. If those answers do not exist, the build is not finished, however finished it looks. ### Is this just an argument against non-technical founders shipping software? No. More people can build software now than at any point in history and that is straightforwardly good. The argument is about what happens once other people start depending on it, which is a different threshold and always was. ## Where these numbers come from Both findings are third-party and public. - Veracode, 2026 GenAI Code Security Report: More than 100 models tested against a fixed task set. Syntax correctness near total, security pass rate 56 percent, roughly 44 percent of tasks introducing a risky vulnerability. - RedAccess scan of publicly reachable vibe-coded applications, May 2026: Roughly 380,000 assets scanned across Lovable, Base44, Replit, and Netlify, with about 5,000 exposing sensitive corporate or personal data. The platforms named have disputed parts of the finding. ========================================================================== # Monolith Decomposition > A scoped AI Pod that extracts a monolith one bounded piece at a time, with a working system at every step. 250 to 600 story points, phased. Source: https://www.koombea.com/ai-pods/catalog/monolith-decomposition/ --- One codebase, fifteen years of decisions, and a deployment everyone dreads. This Pod carves it into pieces that move independently, one at a time, behind interfaces that do not change. ## The problem The system is not broken. It serves customers, it holds revenue, and it cannot be switched off. What broke is the economics of changing it. A one-week feature takes six, and nobody can say exactly why. The usual proposal is a rewrite. Eighteen months, no new features, and a promise that the replacement will be better. That bet has a poor record. It asks the business to pay twice: once for the rewrite, and once for the year of standing still. We move pieces instead. Each phase extracts one bounded part of the system, behind an interface its consumers never notice changing. You stop when the economics are good enough, not when the plan says you are finished. - A working, deployable system at the end of every phase - Legacy interfaces preserved until the last consumer has moved - The cost of change measured before and after, not just the stack ## What this Pod ships - **Bounded extraction**: One part of the system moved out at a time, with its data, behind an interface that stays stable for everything still calling it. - **Zero-downtime migration**: Data moves without the business pausing, using dual writes and a verified cutover rather than a maintenance window. - **Characterization tests**: Tests that pin down what the old code actually does before it moves, which is the only safe basis for changing it. - **Measured cost of change**: Lead time and change failure rate tracked across the program, so the argument for continuing is evidence rather than faith. ## How a slab gets emptied ## Why this is phased, always A single 600 point commitment on a system nobody fully understands would be a guess. We do not price guesses. Each phase is scoped and committed on its own, informed by what the previous phase taught us about the codebase. Phase 1 is deliberately the piece with the clearest boundary, not the piece causing the most pain. Proving the extraction pattern on something tractable is what makes the harder phases predictable. ## What it costs 250 to 600 story points across the program, split into phases of roughly 80 to 150 points each. Each phase carries its own committed price, approved before it starts. If the system has not been assessed yet, start with a Legacy Assessment. 30 to 50 points buys the decomposition plan this Pod executes, and it credits in full against the first phase. - Points: 250 to 600 total, committed one phase at a time - Each phase leaves a system that runs and deploys - You can stop between phases without stranding the work - 30 day warranty from written acceptance of each phase ========================================================================== # Products > Three products we built and run ourselves. They are the evidence that AI-First delivery is a working reality rather than a positioning word. Source: https://www.koombea.com/products/ --- Any agency can say it is AI-First. These are three products we built, run, and use on client work, which is a harder thing to say and an easier thing to check. ## What we build and run - ScopeGen AI: Turns a client conversation into an estimated work breakdown. - StorefrontOS: A Shopify store as a native mobile app, in 2 to 3 weeks. - Tambora: The QA platform our Pods plan, run, and report testing on. ## Why a development partner ships its own products A fixed price per story point only holds if the machinery behind the estimate is real. ScopeGen AI produces the work breakdown your price comes from, and Tambora runs the testing that decides whether the work passes. Both are load-bearing, not marketing. StorefrontOS is the same argument in product form. A Shopify storefront as a native app in 2 to 3 weeks is only possible because the commerce foundation is already built and already in production elsewhere. You can ask to see any of the three running. ========================================================================== # Technology and SaaS Software Development > Product engineering for technology companies: multi-tenant SaaS, platform APIs, and the modernization work that restores velocity. Source: https://www.koombea.com/industries/technology/ --- Technology companies do not hire a partner for capability. They hire one for throughput on a specific bet, without slowing the team they already have. ## What makes this different The two things they usually want are throughput on a defined bet that the core team cannot absorb, and someone to take on the modernization work that everyone agrees is necessary and nobody has capacity for. Both suit a committed scope at a known price. Where a technology client wants to direct the work themselves against their own backlog, Staff Augmentation is the honest answer and we will say so. - Multi-tenant SaaS architecture, including the tenancy decisions that are hard to reverse - Platform APIs and developer experience treated as product surface - Modernization delivered incrementally, with a working system at every step - A committed scope so the bet has a price before you fund it ## What we build here - **Multi-tenant SaaS**: Isolation, provisioning, and per-tenant configuration done deliberately. - **Platform APIs**: Versioning, contracts, and documentation as first-class deliverables. - **New product bets**: A scoped, priced Phase 1 that proves or kills the idea quickly. - **Scale work**: Finding and fixing the constraint before your growth does it for you. - **Test debt**: Building the regression safety net that lets a team move again. - **Developer experience**: Reducing the friction that quietly caps your own team's output. ## Proof from this segment FlightLogger tracks over 1,500 airlines and more than 30,000 airports, with tens of thousands of monthly active users. LINCSPRING replaced an off-the-shelf LMS that could not scale past its own permission model. ## Where to go next - FlightLogger: Case study: real-time tracking across 1,500 airlines and 30,000 airports, and Gold for UX at the Indigo Awards - LINC: Case study: an off-the-shelf LMS replaced once its permission model became the thing capping growth - Purgo AI: Case study: multi-agent AI that already worked, with no product around it, taken to a SaaS platform that builds a data pipeline in 15 minutes - Platform Modernization: The capability this segment leans on most, delivered as incremental cutover rather than a rewrite you cannot stop ========================================================================== # Locations > Koombea works from Barranquilla, Colombia and Naples, Florida, with a remote-ready team beyond them. Source: https://www.koombea.com/locations/ --- Two offices. Delivery runs from Barranquilla, Colombia, on Eastern time with no daylight saving shift. Naples, Florida is our United States base. ## One delivery center, several front doors Being honest about this is more useful than listing offices as though each held a delivery team. Our engineering happens in Barranquilla and across a remote-ready team. Naples is our United States base. The practical consequence for you is the time zone. Colombia does not observe daylight saving, so we are on New York's clock in winter and one hour behind it from March to November. Either way our working day sits inside the US Eastern business day all year. - Barranquilla, Colombia: the delivery center - Naples, Florida: our United States office - A remote-ready team across more than a dozen countries - Inside the US Eastern business day year round, differing by at most one hour seasonally ========================================================================== # Careers > Remote-first jobs building production software for real users. See the open roles, the benefits, and our unedited Glassdoor scores. Source: https://www.koombea.com/company/careers/ --- We build production software for real users, in small Pods, since 2007. What you ship matters here. Where you sit does not. ## Meet us We are a distributed team of designers, engineers, QA specialists, delivery managers, and operators, building digital products since 2007 from Barranquilla and wherever our people live. Respect and discipline shape how we work. "Our team is our greatest asset, and we pride ourselves on creating a culture where employees feel challenged, valued, and inspired. Over time, Koombea has established a reputation for being a great place to work, and we are extremely proud of that." Jonathan Tarud, Koombea CEO ## Remote first We hire where the talent is, not where a building is. Pods are put together across time zones, and the work is organized around that rather than in spite of it. That shows up in how a day actually runs. Decisions land in writing so nobody has to be awake to be included, and you are measured on what you ship rather than on the hours a tracker recorded. - Async by default, with decisions written down - Enough overlap with your Pod to pair, review, and unblock - Judged on the work, not on time at a desk - Set your own hours around the people you build with ## Koombea's team Every Pod is cross-disciplinary, so whichever of these is your craft, you work next to the other seven every day. We hire people who care about the product behind the ticket and write their decisions down. - UI/UX Design - Mobile Development - Sales and Marketing - Project Management - Front-End Development - Quality Assurance - DevOps - Back-End Development ## The team We get together when it helps and work apart the rest of the time. Either way, the work happens in the open. ## Employee benefits Our people matter. These are the things that come with the job, wherever you happen to work from. - **Remote by default**: Work from anywhere that fits your needs. The team is spread across several countries and the job was written for that from the start. - **Flexible work hours**: Set your schedule around the hours your Pod needs to overlap. - **Paid time off**: Paid holidays and paid time off you can use when you need to disconnect. - **Health insurance**: Medical, dental, vision, and life insurance options for you and your family. - **Wellness and growth**: Support for mental health, professional development, and role-specific learning. - **Competitive pay**: Salary measured against the market, plus a 401(k) match. ## What people say about working here We would rather you heard it from the team than from us. These are the Glassdoor numbers as they stand today, including the ones we are still working on. We do not curate them. Overall rating on Glassdoor: 4.5 out of 5. Across 89 reviews - Diversity and inclusion: 4.7 out of 5 - Culture and values: 4.6 out of 5 - Work/life balance: 4.3 out of 5 - Compensation and benefits: 4.3 out of 5 - Senior management: 4.1 out of 5 - Career opportunities: 3.9 out of 5 - 93% Would recommend to a friend - 96% Approve of the CEO - 72% Positive business outlook ## Open positions Every role below is remote. Applications go straight to our job board, and a person on our team reads them. - DevOps Engineer (AI Fluency): Full-time, remote Openings track the roadmap, so new roles reach the job board first. ========================================================================== # Maintenance and Support > Ongoing maintenance, monitoring, dependency and security upkeep for products in production. A 30 day warranty, then four severities with published response targets. Source: https://www.koombea.com/capabilities/maintenance-and-support/ --- A product in production needs dependency updates, security patches, monitoring that someone reads, and a path for the bug a customer found on Sunday. ## The problem This is the thing clients buy most often. Software does not hold still. Dependencies deprecate, certificates expire, an OS release breaks an assumption, and volume grows past what an early decision could carry. Left alone, that accumulates quietly for two years and then presents as a crisis with no obvious cause. Handled continuously, it is a small, predictable draw on capacity. While a Pod is running, maintenance draws from the same point capacity as feature work, so you can see the trade you are making. When a month goes heavily to upkeep, that shows in the capacity report, and it becomes a conversation rather than a surprise. After a build ends, this becomes its own thing. A 30 calendar day warranty covers qualifying defects in our code at no cost, starting from your written acceptance of the production launch. Beyond that, support is a separate monthly plan sized in points, from light upkeep on a stable product through to priority queueing on one that is still moving. - A 30 day warranty on delivered software, then an optional monthly plan - Dependency and security upkeep on a schedule, not on an incident - Monitoring configured so alerts mean something and get read - Four severities with response targets, agreed before launch ## What this covers - **Security upkeep**: Patching, dependency audits, and response to disclosed vulnerabilities. - **Monitoring that is read**: Alerting tuned to the business fact, reviewed as part of the cycle. - **Performance drift**: Catching slow degradation before users call the product slow. - **Infrastructure care**: Cost, capacity, and configuration reviewed rather than left to grow. - **Production issue path**: Agreed severities and response expectations, written down. - **Continuity**: Documentation and access that survive people changing jobs. ## If it is not tested, it does not exist Monitoring is the thing every partner claims and almost nobody proves. An error tracker with no DSN configured, a log line nobody ships anywhere searchable, an alert routed to a channel that was muted last quarter: all of these look like observability on a slide and none of them will tell you when your product breaks. So we treat it as a feature with its own acceptance criteria. If error capture is not verified by deliberately triggering an error and confirming it arrived with the right context, it is aspirational. The same goes for the structured log lines a background job emits and for the alert that is supposed to page someone. There is a specific reason this matters more on AI-First delivery. The failures that reach production from generated code are rarely crashes. They are plausible interpretations of an ambiguous requirement that produce quietly wrong results. They are contracts that drifted after the integration was written. They are queries that are correct but generate one call per row. None of those announce themselves. All of them are visible in performance traces and error context if the wiring is real. - Error tracking across frontend, backend and background jobs, with release and user context - Performance tracing with a p95 baseline per endpoint, so a regression is a number rather than a feeling - Query-explosion detection, which is the most common performance smell in generated code - Structured logs with a correlation ID, so one user action can be reconstructed end to end - Health checks that test real dependencies, not just that the process is alive - Alerts routed to a named owner per area, by severity ## Four severities, agreed before you need them Response targets are business hours, on reproducible defects in code we wrote, while a support plan is active. Published here rather than negotiated during an incident. | | Initial response | Containment | Target resolution | |---|---|---|---| | P1. Critical: a core flow is down with no workaround | Within 2 business hours | Within 1 business day where feasible | Within 2 business days for defects in our code | | P2. High: major degradation, partial workaround exists | Within 4 business hours | Within 2 business days where feasible | Within 5 business days for defects in our code | | P3. Medium: partial malfunction, limited business impact | Within 1 business day | As mutually prioritized | Next available cycle | | P4. Low: cosmetic or minor usability | Within 2 business days | Not applicable | Prioritized into the backlog | These are not an uptime guarantee and do not include 24/7 monitoring or after-hours on-call unless separately contracted. Where a third party controls the fix we investigate and contain, but cannot commit to a resolution window that is not ours. ## Where a support plan stops A maintenance plan is business hours, Monday to Friday. It is not an uptime guarantee and it is not an operations team. Round-the-clock monitoring, an on-call rotation, and infrastructure operations such as provisioning, scaling and disaster recovery are all real work, and all of them are scoped separately rather than quietly assumed into a monthly fee. Two other boundaries are worth saying out loud. A major framework or runtime upgrade that needs a coordinated migration is a project, not maintenance. And penetration testing and formal security audits belong to our governance practice, on a retainer or fixed fee, because an audit opinion is not a story point. Unused capacity in a support plan does not roll over, which is the opposite of how banked points work on a Pod. We would rather you knew that before you picked a tier than after. - Business hours support, Monday to Friday, excluding company holidays - 24/7 monitoring, on-call, and infrastructure operations scoped separately - Major version migrations handled as a project, not as upkeep - Anything above the plan capacity is estimated and agreed before it starts ## What drives the estimate Support plans are sized in monthly point capacity, so choosing a tier is really a forecast of how much change the product will absorb. Two products with identical feature sets can need very different plans. The dominant factor is dependency surface. A product resting on six third-party services inherits six other companies' release schedules, deprecations and outages, and someone has to absorb that whether or not you planned for it. - How many third-party services you depend on, and how aggressively each deprecates - Whether the product is still changing or genuinely stable - Regulated data in scope, which makes patching a compliance obligation rather than a preference - Mobile in the mix, because OS releases arrive on Apple and Google's schedule, not yours - Traffic growth, which turns yesterday's reasonable decision into today's bottleneck ## Questions worth asking ### Can you maintain a product another partner built? Yes, and it starts with a discovery pass so we know what we are agreeing to support. Committing to response targets on a codebase we have not read would be a promise we could not keep. The documentation pass under platform modernization is often the right first step. ### Does unused plan capacity roll over? No. Banked points on an AI Pod carry forward for 90 days. Unused capacity in a support plan does not roll over unless the agreement says otherwise. Do not assume the Pod behavior applies here. ### What is covered by warranty versus by a plan? The 30 day warranty covers qualifying defects in code we wrote, at no cost, from your written acceptance of the launch. It does not cover new features, changes you or a third party deployed, or third-party failures. After it expires, a support plan is how the same work keeps happening. ### Do we need a plan at all? Not necessarily. A genuinely stable product with few dependencies can go a long time on nothing, and we will tell you when that is your situation rather than selling you a retainer. The products that need one are the ones still changing or carrying regulatory obligations. ### What if we need something outside the plan? It is estimated in points and agreed in writing before it starts, at the same rate as any other work. There is no penalty and no premium for being outside the plan. ## Support measured in years Maintenance is why several of the engagements on our work page have run for years rather than months. ========================================================================== # LINC > An off-the-shelf LMS left supervisors with no visibility. LINCSPRING replaced it with role-based access, G Suite integration and microcredentials. Source: https://www.koombea.com/work/linc/ --- An off-the-shelf LMS that could not scale, replaced by LINCSPRING. ## The problem LINC, the Learning Innovation Catalyst, had started on an off-the-shelf LMS. It gave supervisors no visibility of their teams' data, integrated with little, required manual file management, and had permission controls too coarse for how the organization actually worked. The consequence was that every new client meant manual onboarding work, which meant growth was capped by administration rather than by demand. ## What we built LINCSPRING, a customized multi-user web platform with collaborative learning tools, personalised playlists, research-based learning cycles, microcredentials, and community discussion. It integrates with G Suite through authenticated APIs and adds role-based access control with dashboards scoped to what each role needs to see. "The Koombea team never tried to sell me on the fact that I needed to work with them to develop LINCSPRING. Koombea forced us to consider precisely which aspects of our MVP would be critical to our success, and we were able to launch a new solution quickly thanks to that critical analysis." Tiffany Wycoff, Co-founder, LINC ## What happened The source case study publishes no financial or time-to-launch figures. - Over 500 users on LINCSPRING at the time of writing, with 1,000+ daily users anticipated - Rapid acquisition of new business across North and South America - Client feedback described the platform as incredibly intuitive, easy to use, and customizable ## Delivery notes Stack: Web platform, G Suite API integration, role-based access control. Capabilities applied: Product Engineering, Integrations and Data. Delivered as a committed scope, estimated in story points and priced before work began. ========================================================================== # Stack Upgrade > A scoped AI Pod that brings a framework and runtime up to a supported version, architecture untouched. 120 to 300 story points. Source: https://www.koombea.com/ai-pods/catalog/stack-upgrade/ --- Framework, runtime and dependencies brought up to a supported version. The architecture stays exactly as it is, because this is a maintenance problem and treating it as a redesign is how it never gets done. ## The problem Upgrades get deferred because they are invisible. Nobody asks for one, no customer notices when it lands, and there is always a feature worth more this quarter. So the version gap widens quietly for three years. Then it stops being invisible. A security advisory lands with no patch for your version. A hosting provider drops the runtime. A hire turns down the offer after seeing the stack. By then the upgrade is four major versions of breaking changes rather than one. We do this as contained work with a committed price. The reason it never happens is that nobody can say what it will cost. - Rails, Node, .NET, Java, React, Angular and the frameworks around them - No architecture changes, no opportunistic refactoring, no scope creep - Behavior verified against tests, not against someone's memory ## What this Pod ships - **A safety net first**: Characterization tests over the paths with no coverage, so the upgrade has something to be verified against. - **Staged version jumps**: One major version at a time, each one deployable, rather than a single leap nobody can review. - **Dependency and CVE clearance**: Abandoned packages replaced, known vulnerabilities closed, and a lockfile that resolves without warnings. - **A pipeline that keeps you current**: Automated dependency updates and a documented cadence, so this is the last time it accumulates. ## Nothing merges on hope ## What we will not do here We will not rearchitect anything while we are in there. The temptation is real. A codebase mid-upgrade exposes every decision you regret. Acting on it is how contained work becomes open-ended work. Anything worth changing gets written down and estimated separately. You decide whether to do it, with a price attached, after the upgrade lands. ## What it costs 120 to 300 story points. The drivers are how many major versions you are behind and how much test coverage exists today. Coverage matters more. An upgrade with a real test suite is routine. One without means building the safety net first. We size it from your repository before quoting, so the number reflects your actual dependency graph rather than an average. - Points: 120 to 300, committed before work begins - Sized from your repository, not from a template - Deployable at every version step, never one large cutover - 30 day warranty from written acceptance ========================================================================== # Company > Building digital products since 2007, from Barranquilla, Colombia and Naples, Florida. How we work, who we are, and what we can prove. Source: https://www.koombea.com/company/ --- We started in Barranquilla in 2007 and now work from two offices, in Barranquilla and Naples, Florida. What has stayed constant is the belief that a development partner should commit to an outcome, not invoice for an attempt. ========================================================================== # Product Design > User research, wireframes, prototypes and design systems that survive contact with engineering, delivered inside the same Pod as the build. Source: https://www.koombea.com/capabilities/product-design/ --- A design that cannot be built as drawn is not a design, it is a picture. Ours are produced in the same Pod that ships them. ## The problem The usual failure is organizational. Design happens in one company, engineering in another, and the handoff is a file. Every ambiguity in that file becomes a decision an engineer makes alone, at speed, without the context that produced the drawing. Because design and delivery sit in the same Pod here, each flow is validated as a clickable prototype before implementation, and the design system is built as real components rather than as a library of symbols nobody can use. We also research before we draw. Not a six-week study, but enough contact with actual users to know which of the three plausible flows matches how people already think about the task. - Clickable prototypes to validate direction before a line of code - Design systems delivered as usable components, not just as files - Research sized to the decision, not to a template - Accessibility considered in the flow, not bolted on at the end ## What this covers - **Product and UX design**: Flows, wireframes, and interface design for real products. - **Prototyping**: Clickable validation of direction before implementation starts. - **User research**: Interviews and testing scoped to the decision at hand. - **Design systems**: Components, tokens, and documentation engineering can actually use. - **Accessible by design**: Contrast, focus order, and semantics decided during design. - **Figma delivery**: Handover that matches what gets built, because the same Pod builds it. ## UX and UI Are Not the Same Purchase ### UX — Whether the flow matches the task. User experience is a question about structure. Which screens exist, in what order, what happens when something is missing, and whether the path matches how someone already thinks about the job. Get this wrong and no amount of interface work recovers it. - Flows validated as a clickable prototype before implementation - Empty, loading, partial, error, offline, and permission-denied states decided in design - Accessibility built into the flow, including focus order and semantics - Platform conventions respected, because iOS, Android, and the web do not behave alike ### UI — Whether the surface is usable and yours. The interface layer carries the brand and does the moment-to-moment work of being legible, tappable, and unambiguous. We build it as a design system of real components rather than a page of symbols, so the second screen costs less than the first. - A design system delivered as components engineering can use - Contrast and target sizes checked against WCAG, not eyeballed - Your brand carried through the product, not a template with a logo dropped in - Decisions driven by what works rather than by what is current Most requests for "design" arrive meaning the second one. The first is where the money is usually lost, because a beautiful interface over the wrong flow is a faster route to the wrong place. ## How Design Runs Inside a Pod Frame the decision: The question your design has to answer gets written down before anything is drawn. (Days, not a discovery phase) Draw and prototype: Your flows become a clickable prototype. Redirecting a prototype costs a fraction of redirecting an implementation, which is the entire reason it exists. (Cheap to change, on purpose) Test on the prototype: Usability testing happens before implementation rather than after your launch, while the answer is still free to act on. (Five or six conversations, usually enough) Hand to the same Pod: Design runs roughly a cycle ahead of implementation, in the same Pod that ships it. No file goes over a wall, so ambiguity gets a conversation instead of a guess. (One cycle ahead, rolling) Grow the system: Patterns that recur become components in your design system, so each later surface costs you less to design and less to build. (Compounding, not linear) ## Research sized to the decision Research has a bad reputation in product teams, and it earned it honestly. Six-week studies that arrive after the decision was made are theatre, and everyone involved knows it. So we size research to the decision in front of us. If the question is which of three plausible flows matches how people already think about a task, that is five or six conversations and two days, not a discovery phase. If the question is whether an entire product category is worth entering, that is a bigger piece of work and it should be a separate engagement rather than smuggled into a build. The test we apply is simple. If the finding could not change what we build next, we do not run the study. That constraint keeps research cheap enough to actually happen, which is the only way it affects anything. - The question is written down before the method is chosen - Usability testing on the clickable prototype, before implementation rather than after launch - Existing analytics and support tickets read first, because you often already have the answer - Findings delivered as decisions and open questions, not as a slide deck nobody opens ## When the product does not exist yet Sometimes the honest answer is that you have nothing to design yet, because the shape of the thing is not decided. That work is discovery, and it produces artefacts rather than screens. What you get out of it is the material your estimate can be built from. A backlog broken into epics and user stories, a high-level architecture stating what your system has to talk to, and a service blueprint showing where your product touches your operation. Those three turn a vision into a scope that can be priced in story points. Discovery is a separate engagement, not something smuggled into your build. It is also the right first step more often than people expect, and you will be told that rather than handed screens for a product nobody has bounded yet. - A backlog as epics and user stories, which is what gets priced - High-level architecture, so integrations are known before they surprise you - A service blueprint, showing where the product meets your operation - A scope that can be estimated in story points rather than in optimism ## What drives the estimate Design and engineering come out of the same capacity here, so design work competes with features rather than sitting in a separate budget you forget about. That makes it worth knowing what actually costs. The answer is states, not screens. A screen is one drawing. A screen with empty, loading, partial, error, offline and permission-denied variants is six, and those variants are exactly what gets skipped in a handoff and then invented by an engineer at speed. - Distinct states per surface, which is the real unit of design work - Whether Tambora can be the starting point or the product needs its own visual language - The accessibility conformance level, if one has to be verified rather than merely intended - How many platforms the design has to survive, and whether they can share patterns - Research depth, which we size to the decision rather than to a template ## Start with a free design audit If you already have something built, the cheapest way to find out whether this capability is worth buying is to watch us assess your product first. A written heuristic audit, back in two to three business days, at no cost. ## Questions worth asking ### What is the free design audit, and what is the catch? It is a heuristic review of a product you have already built, returned as a written report and a prioritized list of usability issues in two to three business days. The catch is that we hope you like the work enough to talk about the rest. The documents are yours either way, and most audits do not turn into engagements. ### Can we bring our own designer? Yes, and it works well when the boundary is clear. Your designer owns the visual direction and the flows; we own buildability and the state coverage. What does not work is a handoff with no conversation, because every ambiguity in the file becomes a decision an engineer makes alone. ### Do we get the Figma files? You do. Designs, source and documentation all become your property on full payment. The design system ships as usable components rather than only as a library of symbols. ### Is design a separate phase before development? No. Design runs ahead of implementation on a rolling basis inside the same Pod, typically a cycle or so in front. A long design phase before any code produces beautiful work that has never met a real constraint. ### What if we do not like the direction? That is what the clickable prototype is for, and it is deliberately early and cheap to change. Redirecting a prototype costs a fraction of redirecting an implementation, which is the entire reason we validate before building. ### Do you do brand and marketing design too? Product design is the capability we sell. We handle the product surface and the design system it needs. Full brand identity work is outside this and we will say so rather than take it on badly. ## Awarded product work since 2019 Every Indigo Design Award this design work has taken since 2019, with the category it was given in and the product it was given to. ### 2025 (8 awards) - Silver in Mobile App: Kunstrux - Silver in UX, Interface & Navigation: Purgo - Bronze in Mobile App: Gratitude - Bronze in UX, Interface & Navigation: Kunstrux, Draymatics, Gratitude - Bronze in Website Design: Purgo, Draymatics ### 2024 (10 awards) - Silver in Apps: FCC, DEVNAUT, Tuily - Silver in Mobile App: Sword and Scale, Tuily - Silver in UX, Interface & Navigation: DEVNAUT, Tuily - Bronze in UX, Interface & Navigation: Sword and Scale, FCC, Tuily ### 2023 (14 awards) - Gold in Mobile Responsive Design: RefMasters, Fashioned Health - Silver in Mobile App: RefMasters, Fashioned Health - Silver in Mobile Responsive Design: Trainerz, Wait Time - Silver in UX, Interface & Navigation: Wait Time, NINI and LOLI - Bronze in Mobile App: Trainerz, Wait Time - Bronze in UX, Interface & Navigation: RefMasters, Trainerz, Fashioned Health - Bronze in Website Design: NINI and LOLI ### 2022 (12 awards) - Gold in Mobile Responsive Design: Do It Center - Silver in Mobile App: Avidus, Do It Center - Silver in Mobile Responsive Design: Minnect - Silver in UX, Interface & Navigation: Avidus, Minnect, Do It Center - Bronze in Mobile App: Minnect - Bronze in Mobile Responsive Design: Avidus - Bronze in UX, Interface & Navigation: Joynup - Bronze in Website Design: Joynup, Do It Center ### 2021 (5 awards) - Gold in Interactive Design: Koombea - Gold in Mobile Responsive Design: Koombea - Gold in Website Design: Koombea - Silver in UX, Interface & Navigation: Koombea - Bronze in Animation & Illustration for Websites: Koombea ### 2020 (8 awards) - Gold in Mobile App: Luna - Gold in Mobile Interaction & Experience: Nab - Gold in Website Building Software: LINCSPRING - Silver in Interactive Design: Nab - Silver in UX, Interface & Navigation: Nab, LINCSPRING, Luna - Silver in Website Design: Nab ### 2019 (1 award) - Gold in UX, Interface & Navigation: FlightLogger ## Where to go next - Free Design Audit: A written heuristic review of what you have already built - Auditoría de diseño: La misma auditoría, en español - Product Engineering: The capability design runs a cycle ahead of - Nab: Case study, and an Indigo winner - How Pricing Works: How design work gets priced alongside the build ========================================================================== # Data and Integrations > A scoped AI Pod that connects the systems running your business, so the same record stops being typed into three tools. 80 to 250 story points. Source: https://www.koombea.com/ai-pods/catalog/data-and-integrations/ --- So someone types the same record into three tools, the numbers disagree by Friday, and every report starts with an argument about which system is right. This Pod ends that. ## The problem Integration debt does not announce itself. It arrives as a job that is half copy and paste. As a monthly reconciliation nobody can explain. As a leadership team that quietly stopped trusting its own dashboard. Nobody counts the cost, because it never appears as a line item. It shows up as a slow month-end close. As a report that starts with an argument. As decisions made against numbers that were wrong for a fortnight before anyone checked. We connect the systems, decide which one owns each record, and make the failures loud. Most integration disasters are not caused by a sync breaking. They are caused by a sync breaking quietly. - One system owns each record, and the others read it - Every failure raises an alert with the payload attached - Reprocessing is a documented action, not an engineer with database access ## What this Pod ships - **Integrations that survive**: Retries, backoff, idempotency and dead-letter handling, so a third party being briefly down is not a data loss event. - **Pipelines and sync**: Scheduled and event-driven movement between your systems, with the transformation logic in one reviewable place. - **A record ownership map**: Which system is authoritative for each entity, written down, which is the decision that actually resolves the disagreements. - **Observability**: Dashboards for volume, lag and failure rate, plus alerts that name the record that did not make it. ## Three systems, one record ## The part people skip Deciding which system owns the customer record is not a technical question. It is the one that makes or breaks the work. When two systems both believe they are authoritative, you get a record that flips between two values every fifteen minutes. So we force that decision early, in writing, with whoever owns the process. Skipping it is why the last attempt did not hold. ## What it costs 80 to 250 story points. The drivers are how many systems are in scope and how well documented their APIs are. A modern API is routine work. A nightly file drop is not. We scope each connection on its own. Start with the two that hurt most and add the rest later, without re-planning anything. - Points: 80 to 250, committed before work begins - Scoped per connection, so the program can start small - Salesforce, HubSpot, NetSuite, SAP, Shopify, Stripe and the rest - 30 day warranty from written acceptance ========================================================================== # Nab > A prototype became a Progressive Web App aggregating more than 25 collectibles vendors into one community hub. Four Indigo Awards followed. Source: https://www.koombea.com/work/nab/ --- A prototype turned into a Progressive Web App aggregating 25+ vendors, and four Indigo Awards. ## The problem Nab had a basic prototype and a clear ambition. CEO Mike White did not want a minimum viable product, he wanted what he called a Minimum Lovable Experience: something collectors would actually enjoy using. The platform also had to aggregate more than 25 vendors while staying inside a budget that would not stretch to a US agency rate card. ## What we built A Progressive Web App acting as a community hub for pop and geek culture collectibles, aggregating new releases from Walmart, Target, Best Buy and Barnes & Noble alongside niche stores, across toys, games, movies, comics and vinyl. Design decisions included non-invasive advertising, straightforward category navigation, social sharing and follows, personalisation, streamlined onboarding, and an accessibility focus. "It is impossible for us to comprehend everything there is to know about developing a product like Nab. The Koombea team had the technical knowledge for things like usability tests and design. They definitely helped us figure out what worked and what didn't." Mike White, CEO, Nab ## What happened - Four Indigo Design Awards within months of launch: Gold in Mobile Interaction and Experience 2020, and Silver in UX Interface and Navigation, Interactive Design, and Website Design - The CEO noted the engagement was significantly more affordable than similar US companies - The team delivered on everything and added extra value, in the client's words ## Delivery notes Stack: Progressive Web App. Delivered as a committed scope, estimated in story points and priced before work began. ========================================================================== # Design Audit > A free heuristic review of your product's UX. You get a written audit and a prioritized list of usability issues in two to three business days. Source: https://www.koombea.com/design-audit/ --- Send us what you have built. You get back a written heuristic audit and a prioritized list of usability issues, in two to three business days, at no cost. ## Most usability problems are already visible Teams rarely lack ideas about what is wrong with their product. They lack an ordered list. Support tickets say one thing, the last stakeholder meeting said another, and nobody can say which fix moves a number. A heuristic evaluation settles that. It measures the interface against established usability principles rather than against taste, so the output is a list of specific defects with a severity attached. You can argue with a preference. It is much harder to argue with a broken error state. This audit is free and it is not a sales call in disguise. You get the document whether or not you ever hire us. - Specific defects, each tied to the principle it breaks - Severity attached, so the list has an order to work through - Written and delivered, so your team can act on it without us - No cost, and no obligation to do anything with it ## How the Audit Works Send us what you have: Fill in the form on this page with a link to the product, a prototype, or a design file. Sketches and wireframes are enough. (Five minutes) We confirm scope: You get an email confirming what we will review and a link to book a short call. If we cannot audit what you sent, we say so here rather than after you have waited. (Same or next business day) Tell us the context: A short conversation about who the product is for and what you need it to do. Usability is relative to a task, so a review without the task is guesswork. (20 to 30 minutes) We run the evaluation: The product is assessed against usability heuristics, surface by surface, including the empty, loading, and error states that reviews usually skip. (Two to three business days) You get the documents: A written audit report and an insights document, listing pain points and usability issues in priority order. (By email) ## What You Get When It Is Done ### Document one — The audit report. The assessment itself. Each surface reviewed against usability heuristics, with the specific defect, the principle it breaks, and how severe it is. Written to be read by a designer or an engineer, not skimmed by a committee. - Findings tied to named heuristics rather than to taste - Severity on every finding, so triage is already done - Empty, loading, and error states covered, not just the happy path ### Document two — The insights list. The shorter document, and usually the more useful one. Pain points and usability issues in priority order, framed as decisions you can act on this quarter rather than as a redesign you cannot fund. - Ordered by impact on the task the user is trying to finish - Scoped so the top items are fixable without a rebuild - Written as decisions and open questions, not as recommendations in general Both documents are yours. Nothing in them is held back pending an engagement, and there is no version of this that arrives as a slide deck read out on a call. ## Who this audit is not for If you only have an idea, there is nothing to evaluate. A heuristic review needs an interface, and running one against a concept produces confident nonsense. Sketches count. Wireframes count. A live product obviously counts. A description of an app you intend to build does not. If that is where you are, the useful conversation is about scope and cost, not usability. Start there instead. ## Request Your Free Design Audit One form, then a confirmation email. We need a link we can actually open. ## Questions worth asking ### Why is it free? Because it is the most honest sample of how we work that we can give you. You see how we assess a product, what we notice, and how we write, before any money changes hands. Some of those audits turn into engagements. Most do not, and the document is still yours. ### What do you need from me? Something we can open. A TestFlight or Play Store link, a public URL, a Figma file, or exported wireframes. If the product is behind a login, send credentials for a test account rather than a real one. ### Can you sign an NDA first? Yes, and first means first. Ask for one and we send it before you describe the product or send us anything to look at. You will see our terms before any of it leaves your side. ### How is this different from a usability test? A heuristic evaluation is an expert review against established principles. A usability test puts real users in front of the product and watches what happens. The first is fast and cheap and catches the obvious failures. The second is slower and catches the ones nobody predicted. This audit is the first, and it will tell you whether the second is worth running. ### Will you just tell me to redesign everything? No, and an audit that does is a bad audit. Findings are ordered by impact on the task the user is trying to finish, and the top of that list is almost always a handful of specific fixes rather than a rebuild. If the honest answer is that the product needs more than a patch, you will get that with the reasoning attached. ### What happens after I get the documents? Whatever you want. Plenty of teams take the list and work through it themselves, which is the point of writing it down. If you would rather the fixes shipped inside a Pod alongside the rest of your roadmap, that is a scoping conversation and we will price it before anything starts. ## Awarded design work across four products Design work from these Pods has won Indigo Design Awards for Luna, Nab, Fashioned Health and FlightLogger, including Gold for UX, Interface and Navigation. Koombea has been shipping software since 2007. ## Where to go next - Product Design: How design runs inside a Pod - Auditoría de diseño: Esta misma auditoría, en español - Book a Priority Sync: If you are earlier than an interface - See the work: The products these reviews came out of ========================================================================== # Ongoing Delivery > A Monthly Capacity Commitment that ships against your roadmap in two-week cycles, re-prioritized whenever you need. From 80 story points a month. Source: https://www.koombea.com/ai-pods/catalog/ongoing-delivery/ --- A Monthly Capacity Commitment: a standing quantity of story points delivered against your roadmap every month, re-prioritized in any Priority Sync, with capacity that moves as the roadmap does. ## The problem A fixed bid is the right purchase when the scope holds still. Some roadmaps do not. You know the next quarter roughly, the quarter after that loosely, and the thing you will actually build in March has not been thought of yet. Forcing that into a fixed scope produces a document everyone stops believing by week three. Then a change order every fortnight. Hiring against it is slower and much harder to reverse. A Monthly Capacity Commitment prices throughput instead of scope. You commit to a monthly point capacity. What those points buy gets decided in the Priority Sync, as late as possible. - Priorities re-cut every cycle, at no cost and with no renegotiation - Capacity moves up or down as the roadmap does - A month under the commitment banks the difference for 90 days ## What this Pod ships - **Continuous delivery**: Work reaches production as soon as it clears its quality gate, often several times a week. The cycle is a planning rhythm, not a release date. - **Quality inside the price**: Scenarios written from the spec before the build, enforced as merge gates. QA is not a separate line item. - **A weekly capacity report**: Points consumed against items shipped, so throughput is a number you can audit rather than a feeling. - **Monitoring that feeds the backlog**: Production issues arrive as prioritized items rather than as a separate support conversation. ## What happens to capacity you do not use A month that lands under the commitment banks the difference. A heavier month draws that balance down before anything extra is invoiced. Banked points carry forward on a rolling 90 days. They are not redeemable for cash and they are forfeited if the engagement ends. ## What it costs Capacity is bought in tiers, from a single delivery lane at 80 to 100 points a month up to ten or more lanes from 800 points. A lane commits at the lower bound and typically delivers above it, so the commitment is a floor rather than a forecast. You are never billed per AI call or per seat. Model tokens are covered up to a monthly allowance. Anything above it is passed through at cost, with no markup, within a model configuration you approve in advance, and reported every week. The point is still the only unit of price, and a pass-through never changes what a user story costs. - Starter: 1 lane, 80 to 100 points a month - Growth: 3 lanes, 240 to 300 points a month - Scale: 5 to 7 lanes, 400 to 700 points a month - Enterprise: 10 or more lanes, from 800 points a month ## When this is the wrong answer If you have an internal engineering team, a backlog you already own, and you need capacity you direct yourself, this is the wrong shape. That is Staff Augmentation, at an agreed hourly rate, with you directing the work. ========================================================================== # Governance, Risk and Compliance > Nine services across governance, risk and audit readiness. vCISO, ISMS design, risk treatment, third-party risk, offensive security and certification support. Never story-point priced. Source: https://www.koombea.com/capabilities/grc/ --- Regulated products need more than a feature that behaves correctly. They need evidence, and evidence has to be produced deliberately. ## The problem If you operate in health services or payments, a working product is the easy half. The other half is being able to show a regulator, an auditor, or an enterprise security reviewer why your handling of their data is defensible. That work is different in kind from feature delivery, which is why it is priced differently. Governance, risk and compliance work is never story-point priced. A point measures functional scope. A policy set, a risk register or a Statement of Applicability has none, so a point-based price for advisory work has no unit behind it. One boundary matters more than any capability claim. Koombea does not issue certificates and neither does any development partner. An ISO/IEC 27001 certificate comes from an accredited certification body. A SOC 2 report comes from a licensed CPA firm. A PCI DSS Report on Compliance comes from a Qualified Security Assessor. You engage that party. We do the gap analysis, build the controls, produce the evidence, and get you ready for the room. On completion of a build we provide a written attestation covering the agreed security checks and any known critical or high-severity findings identified within that scope. That is a statement we are willing to put in writing, which is the only kind worth having. - Security leadership on demand, without a full-time hire - A management system built against ISO/IEC 27001:2022, not a folder of documents - A prioritized risk treatment plan, not a maturity score - Vendor risk caught before it becomes yours - Penetration testing you authorize in writing first - Gap analysis, audit readiness, and accompaniment through certification ## Nine services, three pillars Governance sets the direction. Risk management finds what can hurt you. Compliance and audit readiness gets you into the audit prepared. These are the service names, and each one is a defined engagement with a defined deliverable. - **Virtual CISO (vCISO)**: A named security lead for risk decisions, executive reporting, and the control program, without a full-time hire. - **Policies and Procedures Development**: We write your security documentation and keep it current. It fits how your organization actually works. - **ISMS Design and Implementation**: We build and deploy an information security management system against ISO/IEC 27001:2022. - **Risk Assessment and Treatment**: We analyze your posture, name the risks, and order the treatment plan by what matters most. - **Third-Party Risk Management**: We evaluate and monitor your vendors. You do not inherit their vulnerabilities. - **Offensive Security Services**: Network penetration testing and vulnerability management. Findings you can act on, not a scanner dump. - **Gap Analysis**: We measure your environment against the requirement, control by control, and map the path to compliance. - **Audit Readiness**: Technical and documentary preparation. The audit is not the first time you answer the question. - **Certification Support**: We prepare the evidence, answer technical findings, and stay with your team through the assessor's review. ## Which framework, precisely A framework claim is the sentence your legal team reads literally. So here is what each one is, where it stands today, and which part of it is ours. | | What it is | Where it stands | What we do | |---|---|---|---| | ISO/IEC 27001:2022 | An auditable information security management system. An accredited body certifies it after a Stage 1 and a Stage 2 audit. | The 2022 edition restructured Annex A to 93 controls in four themes. The transition period closed on 31 October 2025, so 2013 certificates no longer hold. | ISMS design and implementation, gap analysis, evidence, and accompaniment through both audit stages. | | SOC 2 | An AICPA framework against the Trust Services Criteria. A licensed CPA firm issues the report. | Type I covers control design at a point in time. Type II covers operating effectiveness over a period. SOC 2 with no type stated is not a scope. | Readiness for the type you are targeting, then support through the Type II observation period. | | PCI DSS v4.0.1 | The card brands' security standard. A Report on Compliance needs a Qualified Security Assessor. A Self-Assessment Questionnaire you complete and attest yourself. | The January 2025 SAQ A revision dropped three requirements and replaced them with a site-wide script susceptibility criterion, effective 31 March 2025. A full redirect avoids it. An iframe does not. | Scope reduction first, SAQ eligibility determined honestly, then the controls the remaining scope actually requires. | | HIPAA | A US federal regulation covering the Privacy Rule, the Security Rule and the Breach Notification Rule. The HHS Office for Civil Rights enforces it. | No certification scheme exists. Anyone selling you HIPAA certification is selling something that is not real. Business associates and their subcontractors sit directly in scope. | Security Rule gap analysis, readiness assessment, business associate obligations, and the evidence behind them. | ## How a framework gets satisfied Scope reduction: The first move is always making the regulated footprint smaller. The cheapest compliance work is the work you engineer your way out of needing, and it is the step most partners skip because it shrinks the engagement. (First, always) Gap analysis: Measure the current state against the specific framework, control by control, and produce a list a person can act on rather than a maturity score. Start here. Leading with certification support is buying the end of the process first. (Fixed fee) Control implementation: The engineering work: access control, encryption, logging, audit trails, retention and data residency. This part is a build and is priced in points like any other build. (Delivered by an AI Pod) Evidence production: Documentation produced while the work happens, not reconstructed afterwards. Reconstructed evidence is how audits go badly. (Continuous) Audit readiness: A dry run against the questions your assessor will ask, so the first time you answer them is not in front of the assessor. (Before the audit) The audit itself: Run by the independent third party you appoint. We support it and respond to findings. We do not issue the certificate and neither does any development partner. (Your assessor) ## How this is priced Governance work is never story-point priced, because the deliverable is an assessment and an evidence trail rather than a shipped feature. It prices on four bases instead, and the engagement decides which one applies. The control implementation that comes out of an assessment is a build. An AI Pod delivers that part, pointed like any other build. When a compliance engagement and a build run together, they are two lines on two bases. We state them separately. Folding advisory work into a build total would quietly convert an opinion into a fixed-bid commitment. - A monthly retainer for vCISO, ongoing third-party monitoring, and ISMS maintenance - A fixed fee for a defined assessment: gap analysis, risk assessment, an initial vendor evaluation - A scoped engagement for penetration testing, priced by target count, scope, test depth, and whether retesting is included - A phase or milestone price for ISMS implementation, audit readiness and certification support, tied to audit stages rather than to a delivery calendar ## What drives the number What moves the number is how much regulated data you touch and how much of it you could stop touching. Almost everything else follows from that. - How much regulated data is genuinely in scope after reduction, which is often far less than at the start - Which framework, and which flavour of it, since SOC 2 Type I and Type II are different engagements on different timelines - Your current state: nothing in place, policies but no management system, previously certified and lapsed, or mid-audit - Whether evidence exists already, or starts from nothing - Number of systems and third parties inside the compliance boundary, each of which needs its own diligence - Whether you have appointed an assessor already, and what they have told you - Whether the deadline is yours, or a customer contract, procurement gate, regulator or investor set it ## If we are already building it Every regulated build triggers a compliance conversation. The build creates the trigger and this capability answers it, without anyone having to learn your architecture a second time. Sequencing that works: gap analysis first, because it is small, fixed fee, and produces a roadmap you can defend. - A health platform handling protected health information: Security Rule gap analysis, business associate scoping, policies and procedures - Payments, or anything touching cardholder data: PCI DSS scope reduction, SAQ eligibility, penetration testing - B2B software selling into US enterprise procurement: SOC 2 Type II readiness, then support through the observation period - An international or public sector sales motion: an ISMS against ISO/IEC 27001:2022, then certification support - Any platform with a real vendor footprint: a third-party risk program, designed and then monitored - After launch, any of the above: a vCISO retainer instead of the full-time hire you were about to make ## Accessibility is a separate line WCAG verification sits outside the compliance frameworks above, and we keep it separate on purpose. We deliver it as compliance QA against a stated conformance level, and you get findings you can act on. A general accessibility claim is worth nothing to the buyer who asks for it. A verified level, with the exceptions named, is worth something. ## Governing the AI in the delivery Every engagement now runs on AI-First delivery, and that raises questions procurement asks before a contract is signed. These are our answers, and they are written down rather than improvised per deal. Not every client wants AI used on their project, and that is a legitimate position. When a client has not agreed to it, the agreement governs, and the configuration that would make an agent useful stays out of the repository you can see. - An AI usage policy that states which client data may enter a prompt and which may not - Disclosure and consent recorded per engagement, not assumed from a master agreement - Data classification that names what counts as personal, confidential, or restricted before anyone has to judge it live - Tool vetting per vendor, including model training opt-out status and data retention terms - A distinct identity per agent, scoped to the systems it needs, with no shared credentials across agents or clients - An audit trail of agent actions, plus the named boundaries where an agent stops and a person decides ## Questions worth asking ### Does our data get used to train a model? Not through us. Vendor selection includes checking training opt-out status and data retention terms before a tool is approved for client work, and a tool that cannot be configured to keep your data out of training does not get approved. Ask for the current approved list and we will send it, naming the setting we rely on for each one. ### We have not agreed to AI being used on our project. What changes? The agreement governs, and we hold to it. Where AI use is not disclosed, the committed configuration that makes agents useful is excluded from your repository, and developer machine setup enforces that rather than relying on anyone remembering. If you would like to revisit the position later, that is a conversation, not a default. ### Which agent did what? Each agent runs under its own identity, scoped to the systems it needs and no others, so the action log answers that question by construction. Credentials are never shared between agents or across clients. Secrets are the exception to all agent access: an agent references a variable name and never sees a value. ### Can you make us HIPAA compliant? No partner can, and be sceptical of one that says otherwise. HIPAA compliance is an organizational state covering your policies, training and business associate agreements, not just your software. There is also no HIPAA certification scheme, so nobody can certify you either. We can make your product's handling of protected health information defensible and give you the evidence for it, which is the part that is ours to do. ### Do you issue the certificate? Never. An ISO/IEC 27001 certificate comes from an accredited certification body, a SOC 2 report from a licensed CPA firm, a PCI DSS Report on Compliance from a Qualified Security Assessor. You engage them. We get you ready and support the process. The same boundary applies inside our own service line: a vCISO who designs and runs your management system cannot then independently assess it. ### Is Koombea itself certified? Ask us directly and we will answer in writing, naming what we hold and what we do not. What we can point to today is a development unit appraised at CMMI-DEV/3 and a written attestation on every build. ### What does a vCISO actually do? Owns the security direction, keeps the roadmap current, sits in the reviews your buyers put you through, and answers the questionnaires that arrive with every enterprise deal. It is the judgment of a security leader on a retainer rather than on a payroll, which is the right shape when you need the decisions more often than you need the seat. ### Which SOC report do we need? Tell us who is asking. US enterprise procurement usually means SOC 2 Type II. Type I proves the controls are designed, Type II proves they operated over a period, and that period is why Type II takes longer to reach. SOC 1 is a financial reporting scope and a different conversation. Naming the type is the first step, because SOC 2 with no type is not a scope. ### Which frameworks can you actually evidence? We will tell you plainly per framework rather than listing everything that exists. Where we have direct delivery experience we say so and show it. Where we do not, we say that too, because a framework claim is the sentence your legal team reads literally. ### Where does our data live, and will you sign a BAA? We work from Barranquilla and Naples, Florida. When an engagement touches protected health information or regulated personal data we state the data residency and subprocessor position up front, with whether a business associate agreement or data processing agreement is required and who signs it. Settle that before the work starts rather than during your vendor review. ### Why is this not priced in story points? Because a story point measures delivered functional scope, and an opinion has no functional surface area. Pretending otherwise would produce a number with no unit behind it, which is a number nobody can defend in a negotiation. The control implementation that follows a gap analysis is a build, and that part is pointed normally. ### Is penetration testing included in our build? No. A build implements security practices and ships with a written attestation covering the agreed security checks and any known critical or high-severity findings within that scope. Formal verification is a separate scoped engagement, priced by target count and test depth, because the value of a test is partly that it is not run by the people who wrote the code. Before anything is committed we agree the target list, the testing window, the rules of engagement and written authorization. ### When should we start? Before the architecture is settled, not after. Retrofitting an audit trail, a retention policy or a data residency constraint into a live system is the single most expensive way to acquire it. ## Compliance work in production systems Fashioned Health was built on HIPAA-ready infrastructure with PCI-compliant payment handling through Stripe. Koombea's development unit is appraised at CMMI-DEV/3. Our compliance work has been delivered in finance, where the scope is transactions and cardholder data, in healthcare, where it is the privacy and security of patient information, and in technology, where it is infrastructure, intellectual property and operations. Those engagements sit under confidentiality, so we will walk you through them in the Priority Sync rather than name them on a page. ========================================================================== # Do It Center > Do It Center called their own eCommerce platform a Frankenstein. Rebuilt on Shopify with POS and accounting integrated, bounce rate fell 90%. Source: https://www.koombea.com/work/do-it-center/ --- A Frankenstein eCommerce platform replaced on Shopify. Bounce rate fell 90% and NPS reached 70. ## The problem Do It Center described their existing eCommerce platform as a Frankenstein: confusing UI, a multi-step checkout, minimal product information, and complete dependence on outside vendors for basic updates. The cost was concrete. Promotions such as Black Friday were missed because changes could not be made in time, and the only analytics available were traffic counts. ## What we built A complete Shopify commerce platform with unified order and inventory management, integrated point-of-sale and accounting, personalised customer experiences, and omnichannel purchasing including buy online and collect in store. The store was built responsive across desktop and mobile, with the operations layer treated as the substance of the project. "The intermediate custom application that Koombea built so that Shopify can communicate with our back office is definitely the engine that powers everything we do." Elías Manopla, CIO, Do It Center ## What happened - Bounce rate decreased by 90% - Net Promoter Score reached 70, rated Excellent for the hardware industry, with double-digit growth every month - Average purchase is 5X higher than in physical stores - 75% of online transactions were for in-store pickup - Five Indigo Design Awards for the site ## Delivery notes Stack: Shopify, POS and accounting integration. Capabilities applied: Product Engineering, Integrations and Data. Delivered as a committed scope, estimated in story points and priced before work began. ========================================================================== # FAQ > How Koombea prices work in story points, commits to a scope, and delivers it. Answers on engagement models, scope changes, and timezone overlap. Source: https://www.koombea.com/faq/ --- How an engagement starts, how the price is set before work begins, and what happens when the scope moves. The questions specific to a capability are answered on that capability's page, and indexed below. ## Questions about working together ### How do we start working with Koombea? Start with a conversation about what you are trying to ship. Next comes Scope Alignment, which breaks the work into a Work Breakdown Structure (WBS) and sizes every item in story points. You approve that scope and its price before any engineering begins. ### How do we get a price before we commit to anything? That is what story points are for. We decompose your scope into a WBS, size every item, and price the total at a fixed rate per point. You see the number before work starts, not after. ScopeGen AI does the estimating, calibrated against what past projects actually took, which is what makes a committed price possible instead of a range. ### Can we test how you work before committing to a build? Yes. The lowest-friction way is the free design audit. You send what you have already built, and you get back a written heuristic review and a prioritized list of usability issues in 2 to 3 business days, at no cost. It is a real deliverable rather than a sales call, which makes it a fair sample of how the work reads. ### What are the two ways to work with Koombea? Two, and you pick one per engagement rather than mixing them. AI Pods is the default: a committed scope, priced in story points, delivered in two-week cycles. Staff Augmentation is hourly, for when you already have an engineering team and need capacity rather than a scoped outcome. Under that model you own the backlog and direct the work. ### What happens when the scope changes mid-build? We size and price new scope exactly the way we sized the original, so you see what a change costs before you approve it. Reprioritizing inside the committed scope is a different thing and costs nothing. You re-cut priorities at every two-week boundary, so what matters most this cycle is your call. ### What happens if delivery slips? The commitment is On Time & On Budget. Guaranteed. A fixed price against a committed scope means an overrun lands on us rather than on your invoice. That is also why Scope Alignment is thorough before it is quick. The estimate is the thing we are guaranteeing. ### Do you offer ongoing capacity instead of a fixed scope? Yes, through a Monthly Capacity Commitment with Drawdown. You commit to a monthly volume of story points and draw against it as you scope new work. Unused points bank for 90 days on a rolling basis. They do not convert to cash, and they expire if the engagement ends, because an unbounded bank is an open-ended delivery liability. ### What hours does your team work? Colombia hours, and our working day sits inside the US Eastern business day year-round. How We Work has the exact clock, including the one hour that moves seasonally because Colombia does not observe daylight saving. ### How will we see progress between releases? The two-week cycle is a planning rhythm, not a release gate. Work reaches staging and production several times a week, so progress is something you use rather than something you read about. How We Work lists the reporting cadence that wraps around it. ### Where is Koombea, and how long have you been building software? Koombea has built digital products since 2007, from Barranquilla, Colombia, with a US office in Naples, Florida. More than 200 of the products we have built are in market, and our development unit holds a CMMI-DEV/3 appraisal. ### What industries do you work in? The deepest track record is in FinTech, payments and lending, and health services, where the binding constraint is usually regulatory rather than technical. We also build across Retail, ecommerce, and IoT. If your domain carries compliance weight, raise it in the first conversation rather than the last one. ### Do you work with startups, or only established companies? Both. What changes is the engagement, not the standard of the work. A funded startup shipping its first product and an enterprise replatforming a system it cannot switch off both need a defined scope and a price they can plan against. What differs is how much discovery comes first before you can commit that scope. ## Answered in full elsewhere - How We Work: Working hours and time zone overlap, your point of contact, the reporting cadence, and what happens when something breaks. - Security and Compliance: What we attest to in writing, how we handle your code, data, and access, and where our responsibility ends and yours begins. ## Everything else, by page ========================================================================== # Brand Guidelines > The Koombea AI logo, color palette, gradients and typeface, with the rules for using them. Download the full logo pack. Source: https://www.koombea.com/brand-guidelines/ --- Logo files, color values, typography, and usage rules for digital and print work. ## Our logo The name reflects the origins of our cultural heritage. We chose cumbia, a very popular dance in South America that originated in Colombia. The icon is another representation of that culture. It is a symbolic rendering of the sombrero vueltiao, a traditional hat and a national symbol of Colombia. Neither the name nor the mark is decoration. ## Lockups and clear space The primary logo has two uses: a horizontal lockup with the name and symbol on one line, and a vertical version for everything else. Either is correct. Choose on legibility and on the space the logo has to live in. ## The rules that are not preferences The clear space around every lockup is k, the height of the symbol. Keep that much free on all four sides. It is a minimum, not a target. Each lockup ships in two versions. Use the dark-ground version on dark backgrounds and the light-ground version on light ones, rather than recoloring either. - Do not stretch, rotate, or change the proportions of the lockup - Do not recolor the symbol or the wordmark, and do not add effects to them - Do not place a lockup on a background that leaves the wordmark unreadable - Do not rebuild the lockup by setting the name in type next to the symbol ## Koombea AI color scheme The palette is Cyberpunk-inspired, built on purples, pinks and neon accents. It is chosen to read as advanced technology and digital complexity, which is the category we work in. ## Brand gradients The brand gradient runs at 36 degrees through Caribbean Green, Neon Green, Vibrant Purple and Aqua. The seven linear gradients below are the working set. Each is stated with its angle and stops, so a value can be copied rather than sampled from a screenshot. ## The typeface GT Walsheim is the brand typeface. Inspired by the lettering of the Swiss poster designer Otto Baumberger from the 1930s, it is friendly but precise, and it covers all Cyrillic languages. Designed by Noel Leu, released in 2009 and 2017, available in 32 styles. Use GT Walsheim for the site, for print, and for client deliverables. - GT Walsheim for brand and marketing typography - One typographic scale across the system, checked for accessible contrast ## Our Koombea values - **Passion**: We read the product, not just the ticket. If a specification would ship something that does not work for the user, we say so while changing it is still inexpensive. - **Innovation**: AI-First is a working method here, not a label. AI supports scoping, design, engineering, QA, and deployment so we can fix a price before the work is built. - **Respect**: We say when we are the wrong answer. If another engagement model fits better, you hear that before the contract, with the reasoning attached. - **Discipline**: Every commitment has a mechanism behind it. Scope is fixed in points, capacity is reported weekly, and delays are raised when they happen. ## Where to go next - Download the logo pack: SVG, PNG and WebP, 180 KB - About Koombea: Where the name and the mark come from - Partners and Certifications: The badges and what each one gets you ========================================================================== # Jamar > Jamar sold furniture from PDF catalogs. Now a Shopify Plus store with region- based pricing, smart search and STEP master data behind it. Source: https://www.koombea.com/work/jamar/ --- From PDF catalogs to Shopify Plus, with regional pricing and STEP master data. ## The problem Jamar sold furniture through a static website and PDF catalogs. Moving online meant more than building a storefront: pricing, inventory, payments and product information all lived in existing systems that had to keep agreeing with the store. Their pricing model also varied by region, which most commerce platforms handle badly and which could not simply be dropped. ## What we built A Shopify Plus store with a commercial product catalog, smart search, location-based price segmentation, and a checkout carrying delivery time estimates and location selection. Product data is centralised through STEP master data management, WordPress is integrated with Shopify, and sales staff gained a credit approval estimation tool. ## What happened The source case study publishes no revenue, conversion or traffic figures. - Online purchasing available for the first time, replacing static catalogs - Regional pricing preserved rather than flattened to fit the platform - Product data centralised through STEP, so the store and the business agree - Foundation in place for a mobile app, user portal, and order history ## Delivery notes Stack: Shopify Plus, WordPress, STEP master data management. Capabilities applied: Integrations and Data, Product Engineering. Delivered as a committed scope, estimated in story points and priced before work began. ========================================================================== # Talk to Us > Tell us what you are trying to ship and we will come back with how we would scope it, what Phase 1 would cover, and what it would cost. Source: https://www.koombea.com/contact/ ---

Koombea

United States

Naples, Florida

3811 Airport Road N, Suite 100A
Naples, FL 34105

Colombia

Barranquilla

Carrera 53 # 79-01, Local 301
Barranquilla 080001

Direct

Call us
+1-888-840-3252
Email
hello@koombea.com

Before you pay a Koombea invoice, read how we verify clients and handle payments. We never change payment instructions by email.

Delivery runs from Barranquilla on Eastern time year round, so overlap with US business hours never moves. More about our locations.

========================================================================== # Design System > A scoped AI Pod that builds the components, tokens and documentation that keep a product visually coherent as it grows. 60 to 140 story points. Source: https://www.koombea.com/ai-pods/catalog/design-system/ --- Four shades of the same blue, three date pickers, and a button that behaves differently on two screens. This Pod builds the system that stops it, in design and in code, as one thing. ## The problem Design drift is not a taste problem. It is a throughput problem. Every screen designed from nothing is a decision re-made, a component re-built, and a new set of states nobody tested. It compounds quietly. Two years in, a small change to a form touches eleven copies of that form. The estimate for a trivial request stops making sense to the person who asked for it. The usual failure is a system that exists only in the design tool. It looks complete. Nothing in the product matches it. It is abandoned within a year. So we build both halves together, or it does not hold. - Components exist in the design tool and in the codebase, matching - Tokens drive both, so a color changes in one place - Documentation covers states and usage, not only appearance ## What this Pod ships - **Tokens**: Color, type, spacing and elevation defined once and consumed by both the design tool and the code, including the dark theme. - **A component library**: The components your product actually uses, built with their real states: loading, empty, error, disabled and focused. - **Accessibility built in**: Contrast, focus order and keyboard behavior handled in the component, so every screen inherits it rather than re-testing for it. - **Usage documentation**: When to use each component and when not to, so the system survives the people who built it. ## We build it from what you already have We audit the product first and count what is in use. Most products turn out to need about thirty components. Most have somehow built ninety. That audit is what turns an unbounded design exercise into scoped work. Then we build the real inventory. We start with the components that appear on the most screens, so value arrives in the first week rather than at the end. ## What it costs 60 to 140 story points. The drivers are the size of the component inventory and whether the product needs one theme or several. The audit that settles which number applies is part of the Pod, not an extra purchase. Retrofitting your existing screens onto the new system is scoped separately. It is usually the larger half, and most clients want to do it gradually. - Points: 60 to 140, committed before work begins - Audit included, and it is what sets the final number - Retrofit of existing screens scoped separately, on your schedule - The system is yours, in your repository and your design tool ========================================================================== # Privacy Policy > How Koombea collects, uses, shares and protects personal information, and the privacy choices available to you. Source: https://www.koombea.com/privacy-policy/ --- **Effective date:** August 17, 2026 **Last updated:** August 17, 2026 Koombea, Inc. ("Koombea", "we", "us", or "our") builds digital products for business clients. This Privacy Policy explains how we collect, use, disclose, and protect personal information through koombea.com and related Koombea marketing pages, forms, chat, downloadable content, and communications. This policy covers our website, marketing, sales, recruiting, and business development activities. It does not govern personal information we process on behalf of a client inside a product, platform, or system that we build or maintain for that client. In those cases, the client is responsible for its own privacy notice, and our processing is governed by our contract with the client. ## 1. Personal information we collect We collect the categories of personal information below. | Category | Examples | | --- | --- | | Contact identifiers | Name, business email, phone number, company, job title, and address if you provide one. | | Business and project information | Information you submit in a form, chat, email, discovery call, request for proposal, design audit request, partner inquiry, job inquiry, or other message. | | Commercial and relationship information | Services or content you ask about, pages or forms you interact with, event or newsletter preferences, lead status, and related business communications. | | Device and internet activity information | IP address, browser and device type, operating system, referring URL, pages viewed, timestamps, session activity, cookie identifiers, and similar online activity data. | | Approximate location | General location inferred from IP address, such as city, region, or country. | | Marketing and attribution data | UTM parameters, ad click identifiers, referral source, campaign information, HubSpot tracking identifiers, Google identifiers, and similar measurement data. | | Job inquiry information | Resume, portfolio, LinkedIn profile, work history, and other information you choose to send when asking about roles. | We do not ask you to submit sensitive personal information through this website, such as government identification numbers, financial account credentials, health information, biometric data, precise geolocation, or information about children. Please do not send that information through the site unless we have specifically agreed on a secure process for receiving it. ## 2. Sources of personal information We collect personal information from: - you, when you fill out a form, use chat, email us, book a call, request a proposal, request a design audit, subscribe to updates, apply for a role, or otherwise communicate with us; - your browser or device, through cookies, pixels, local storage, session storage, server logs, and similar technologies; - service providers and business tools we use for hosting, analytics, forms, CRM, advertising, security, website performance, and communications; - advertising, analytics, and business-contact identification partners, where those tools are enabled; and - public or business sources, such as your company website, LinkedIn profile, or business directories, when relevant to a business conversation. ## 3. How we use personal information We use personal information to: - respond to you and provide information you request; - evaluate, scope, price, and propose software, design, AI, commerce, or related services; - operate, secure, troubleshoot, and improve the website; - process design audit, partner, Shopify, StorefrontOS, ScopeGen, contact, and other lead forms; - manage our CRM, pipeline, sales communications, and customer relationships; - send marketing communications about Koombea services, events, updates, and content, subject to your communication preferences and applicable law; - measure website performance, advertising performance, referral sources, and conversion activity; - personalize or improve website experiences and business communications; - support recruiting and evaluate job inquiries; - detect, prevent, and respond to fraud, spam, abuse, security incidents, and technical issues; - comply with legal, tax, accounting, and regulatory obligations; and - establish, exercise, or defend legal claims. We do not use personal information submitted through this website to make decisions that produce legal or similarly significant effects about you by fully automated means. ## 4. AI processing Koombea is an AI-First software delivery company. We may use AI tools to support business activities such as summarizing an inquiry, preparing a scoping note, drafting a project brief, classifying a lead, improving internal workflow, or helping our team respond more accurately. AI processing does not replace human review for sales, scoping, contracting, hiring, or client delivery decisions. Do not submit confidential, regulated, or sensitive information through website forms or chat unless we have agreed in writing on the process and protections for that information. For client work, the use of AI tools is governed by the applicable Master Services Agreement, Statement of Work, data processing terms, and security requirements. ## 5. Cookies and similar technologies We use cookies, pixels, tags, local storage, session storage, and similar technologies to operate the site and understand how it is used. The site may use: - **necessary and preference technologies**, such as local storage for theme and motion preferences, session storage for attribution during a visit, security controls, and form functionality; - **analytics and performance tools**, including tools loaded through Google Tag Manager, Google Analytics, Core Web Vitals RUM, HubSpot, and similar measurement services; - **advertising and conversion tools**, including Google Ads, Meta, LinkedIn, and other tags that may be managed through Google Tag Manager; - **session and behavior analytics**, such as Microsoft Clarity or similar tools when enabled through our tag manager; - **business-contact identification and enrichment tools**, such as RB2B or similar providers when enabled; and - **chat and form tools**, including HubSpot forms, HubSpot tracking, and HubSpot Conversations. Some tags are managed through Google Tag Manager or vendor dashboards and may change over time as we add, pause, or remove business tools. You can control cookies through your browser settings. Some browsers also offer privacy, tracking-prevention, or opt-out preference features. Because those signals are not implemented uniformly across all browsers and vendors, you may also contact us at legal@koombea.com to ask us to process an opt-out request under applicable law. ## 6. When we disclose personal information We disclose personal information to the following categories of recipients: - **Service providers and processors** that host, secure, analyze, maintain, or support the website, CRM, forms, analytics, email, chat, advertising, recruiting, and business operations. - **Professional advisers**, such as lawyers, accountants, auditors, insurers, and consultants. - **Advertising, analytics, and measurement partners**, when we use their tags, pixels, cookies, or platforms to measure performance, attribute leads, or reach business audiences. - **Business-contact and enrichment providers**, when used to identify or enrich business contacts or company-level website visits. - **Affiliates, contractors, and team members** who need the information for the purposes described in this policy. - **Prospective or actual transaction parties**, if we are involved in a merger, financing, acquisition, reorganization, diligence process, or sale of assets. - **Authorities, courts, and other parties** where required by law, legal process, security needs, or to protect rights, safety, and property. We do not sell personal information for money. Some disclosures to advertising, analytics, measurement, or business-contact identification partners may be considered a "sale", "sharing", or "targeted advertising" under certain state privacy laws, even when no money changes hands. Where those laws apply, you may have the right to opt out as described below. ## 7. State privacy rights Depending on where you live and whether a particular privacy law applies to Koombea, you may have rights to: - confirm whether we process your personal information; - access the personal information we maintain about you; - receive a copy of personal information you provided to us in a portable format; - correct inaccurate personal information; - delete personal information, subject to legal and operational exceptions; - opt out of targeted advertising, sale, or sharing of personal information; - limit certain uses or disclosures of sensitive personal information, if any; - withdraw consent where processing is based on consent; and - appeal a decision we make about a privacy request, where applicable. California residents may have rights under the California Consumer Privacy Act, as amended by the California Privacy Rights Act, including the rights to know, access, delete, correct, opt out of sale or sharing, limit certain uses of sensitive personal information, and not be discriminated against for exercising privacy rights. We do not knowingly sell or share personal information of children under 16. Florida residents may have rights under Florida privacy laws where those laws apply. The Florida Digital Bill of Rights applies to certain large controllers and includes rights such as access, deletion, correction, portability, and opt-out rights. Florida law also requires reasonable measures to protect personal information and provides breach-notification obligations for covered entities. To submit a privacy request, email legal@koombea.com. Please describe the right you want to exercise and provide enough information for us to verify and locate your records. We may need to verify your identity or authority before acting on the request. We will respond within the time required by applicable law. If a law does not require us to fulfill a specific request, we may still try to help where doing so is reasonable and consistent with our legal obligations. You may use an authorized agent where applicable law allows. We may ask for proof that the agent is authorized to act for you. ## 8. Email and marketing choices You can unsubscribe from marketing emails by using the unsubscribe link in the message or by contacting us at legal@koombea.com. We may continue to send transactional or relationship messages, such as responses to your request, security notices, legal notices, or service-related communications. Our commercial email practices are intended to comply with the CAN-SPAM Act and other applicable marketing laws. ## 9. Retention We keep personal information for as long as reasonably necessary for the purposes described in this policy, unless a longer period is required or permitted by law. Typical retention periods include: | Type of information | Typical retention | | --- | --- | | Website inquiries, proposal requests, partner inquiries, and sales communications | Up to 24 months after the last meaningful interaction, unless the relationship becomes a client relationship or a longer period is needed for legal, tax, accounting, security, or dispute purposes. | | Client and contract records | For the term of the relationship and then as required for legal, tax, accounting, audit, and dispute purposes, typically up to seven years or longer if required. | | Marketing subscriptions | Until you unsubscribe or the list is retired. We may keep suppression records to honor opt-outs. | | Job inquiries | Up to two years unless you ask us to delete the information earlier or we need to keep it for legal reasons. | | Security logs and technical records | As long as needed for security, fraud prevention, troubleshooting, and legal purposes. | | Analytics and advertising records | According to the settings and retention periods in the relevant provider platforms. Aggregated or deidentified reports may be retained longer. | When information is no longer needed, we delete it, deidentify it, aggregate it, or retain it only as legally required or permitted. ## 10. Security We use administrative, technical, and physical safeguards designed to protect personal information. These may include access controls, encryption in transit, least-privilege access, credential management, vendor controls, monitoring, backups, and incident-response processes. No website, network, or system is perfectly secure. If we determine that a security incident requires notice, we will provide notice as required by applicable law. ## 11. International processing Koombea operates from the United States and Colombia, and our service providers may process information in the United States, Colombia, and other countries. Those countries may have privacy laws that differ from the laws where you live. Where required, we use contractual, organizational, and technical safeguards for international transfers. ## 12. Children This website is intended for business audiences and is not directed to children under 16. We do not knowingly collect personal information from children through this website. If you believe a child has provided personal information to us, contact legal@koombea.com and we will take appropriate steps. ## 13. Third-party links and services The site may link to third-party websites, platforms, social networks, app stores, or services. Their privacy practices are governed by their own privacy policies, not this one. ## 14. Changes to this policy We may update this Privacy Policy from time to time. The updated version will be posted on this page with a new "Last updated" date. Material changes may be communicated more prominently where appropriate. ## 15. Contact **Koombea, Inc.** 3811 Airport Road N, Suite 100A Naples, FL 34105 United States Email: [legal@koombea.com](mailto:legal@koombea.com) ========================================================================== # Test Automation > A scoped AI Pod that converts manual regression testing into automated gates the pipeline enforces on every merge. 80 to 200 story points. Source: https://www.koombea.com/ai-pods/catalog/test-automation/ --- Manual regression testing is the reason your releases are monthly. This Pod converts it into scenarios the pipeline enforces, so shipping stops requiring a person and a spreadsheet. ## The problem Manual regression sets the ceiling on how often you can ship. Verifying a release costs two days, so you release monthly. Every release then carries a month of changes. Large releases fail more often, which makes everyone more cautious, which makes releases larger. Teams break that loop by writing tests. Then they break the tests by not running them on every merge. A suite that runs nightly and is red most mornings is not a safety net. It is a notification everyone muted. So we build gates, not reports. A scenario that does not block a merge does not change behavior. - Every scenario runs on every merge, not nightly - A red gate blocks the merge, with no override by convention - Flaky tests are treated as defects and fixed, not retried ## What this Pod ships - **The critical journeys first**: The paths that carry revenue, automated end to end, because a suite that covers everything equally covers the important things too late. - **Test data that is not a person**: Fixtures and seeding, so running the suite does not depend on someone remembering to reset an environment. - **Pipeline gates**: Wired into CI as a required check, with the run time kept short enough that nobody is tempted to skip it. - **Coverage you can read**: Reporting on what is covered and what is not, so the remaining risk is a known list rather than an assumption. ## Why the order matters Scenarios come from the spec, before the implementation they verify. On an existing product there is no spec to write from. So the first step is establishing what the current behavior actually is, and confirming it with you. That conversation routinely surfaces two or three behaviors nobody intended and everybody now depends on. ## Where the suite sits ## What it costs 80 to 200 story points. The drivers are the number of critical journeys and how testable the application is today. An application with seams and a stable interface is quick. One where everything is welded to the interface needs untangling first. We scope from a walkthrough of your current release process. The estimate then reflects the suite you need, not a coverage percentage someone picked. - Points: 80 to 200, committed before work begins - Scoped from your release process, not from a coverage target - Playwright, Cypress, and the frameworks your team already runs - Handover includes how to write the next one yourselves ========================================================================== # Bug Burndown > A scoped AI Pod that triages and clears a defect backlog, then gates the pipeline so it does not refill. 40 to 150 story points. Source: https://www.koombea.com/ai-pods/catalog/bug-burndown/ --- A defect backlog that only ever gets longer is not a queue, it is a decision nobody made. This Pod clears it against a committed price, then changes the conditions that produced it. ## The problem Four hundred open tickets is not four hundred problems. It is maybe forty real defects. A hundred duplicates. Sixty feature requests filed as bugs. Two hundred that stopped being reproducible a year ago. The backlog stays untouched because it is unreadable. Clearing it competes with roadmap work every sprint, and loses every sprint. Meanwhile the genuine P1 sits somewhere in the middle of it. So we take it as scoped work with its own committed price. Then it stops competing with the roadmap for attention. - Triage first, so the fix budget goes to real defects - Ranked by user impact and revenue exposure, not by report date - Root causes fixed where they are shared, not symptom by symptom ## What this Pod ships - **A triaged, readable backlog**: Duplicates merged, non-reproducible items closed with a reason, and everything left ranked by impact. - **P1 and P2 cleared**: The defects that block users or expose the business, fixed and verified, against a committed point budget. - **A regression test per fix**: Every fix ships with the scenario that would have caught it, enforced as a gate, so it cannot come back quietly. - **Cause analysis**: Where the defects came from, which is usually two or three shared causes rather than a hundred unrelated mistakes. ## Triage is the whole value The first stage reads the whole backlog. It produces a ranked list with an estimate against each real defect. That document is often enough on its own. The fix budget a client feared was six figures turns out to be thirty points. You approve what gets fixed from that list. We touch nothing outside it. Anything we think is worth doing later gets written down with a price, rather than done quietly. ## What it costs 40 to 150 story points. The drivers are the size of the backlog and how deep the fixes go. Triage is a fixed 15 points of that, and it is where the real number gets settled. On a Monthly Capacity Commitment, draw this from your existing lane instead. That is how most clients run it. There is no second billing track. - Points: 40 to 150, with triage a fixed 15 of it - You approve the fix list before any fixing starts - Can be drawn from an existing lane rather than bought separately - 30 day warranty from written acceptance ========================================================================== # Terms of Use > The terms governing use of the Koombea website. Delivery engagements are governed by a separate MSA and SOW. Source: https://www.koombea.com/terms/ --- **Effective date:** August 17, 2026 These Terms of Use ("Terms") govern your access to and use of koombea.com and related Koombea marketing pages, content, forms, chat, and machine-readable files (the "Site"). The Site is operated by Koombea, Inc. ("Koombea", "we", "us", or "our"). These Terms are website terms only. They do not govern software development, design, AI, commerce, security, compliance, support, or other professional services we provide to clients. Client work is governed by the applicable Master Services Agreement, Statement of Work, order form, data processing terms, security terms, and other signed agreements. If these Terms conflict with a signed agreement between you and Koombea, the signed agreement controls. By using the Site, you agree to these Terms. If you do not agree, do not use the Site. ## 1. Who we are Koombea, Inc. 3811 Airport Road N, Suite 100A Naples, FL 34105 United States Contact: [legal@koombea.com](mailto:legal@koombea.com) ## 2. Using the Site You may use the Site to learn about Koombea, read our content, review our services, use public forms, request information, and evaluate whether to work with us. You may not: - use the Site for unlawful, fraudulent, deceptive, harmful, or abusive purposes; - interfere with, probe, scan, overload, scrape in a disruptive way, or attempt to gain unauthorized access to the Site or its systems; - submit malware, malicious code, spam, or misleading information; - impersonate another person or misrepresent your affiliation with an organization; - copy, frame, mirror, resell, or commercially exploit the Site except as these Terms allow; - remove, alter, or obscure legal notices, attribution, or proprietary markings; - use the Site to collect information about others without authorization; or - use the Site in a way that violates applicable law or third-party rights. We may suspend, block, rate limit, or terminate access to the Site where we believe it is necessary to protect the Site, Koombea, users, clients, partners, or third parties. ## 3. Website content The Site may include descriptions of services, products, case studies, blog posts, press releases, pricing concepts, AI Pods, ScopeGen AI, StorefrontOS, Tambora, and other Koombea materials. We try to keep the Site accurate and current, but website content is provided for general informational and commercial evaluation purposes. Statements about timelines, capacity, pricing models, security, compliance, delivery speed, outcomes, or availability become binding only if they are included in a signed agreement with Koombea. Case studies and metrics describe specific engagements or published client results. They are not a guarantee that the same result will occur in another engagement. ## 4. Intellectual property The Site, including its text, design, code, structure, graphics, logos, icons, images, videos, downloadable materials, Markdown files, and other content, is owned by Koombea or its licensors and is protected by intellectual property and other laws. Koombea, the Koombea name, the Koombea mark, AI Pods, ScopeGen AI, StorefrontOS, Tambora, and related names, logos, and branding are Koombea marks or assets. You may not use them in a way that suggests sponsorship, endorsement, affiliation, or ownership without written permission. Client names, logos, screenshots, product names, and marks belong to their respective owners. They appear on the Site to describe work performed, relationships, or public recognition. Subject to these Terms, you may view, download, print, and internally share reasonable portions of the Site for evaluating Koombea or discussing a potential business relationship with us. No other rights are granted. ## 5. Automated access, search, and AI use We publish machine-readable versions of the Site deliberately, including: - Markdown versions of pages at each page URL plus `index.md`; - an index at `/llms.txt`; and - a commercial-site full-text file at `/llms-full.txt`. Our `robots.txt` includes Content Signals. As of the effective date of these Terms, those signals allow search indexing and answer-time AI grounding, and do not allow model training or fine-tuning. You may use publicly available Site content and machine-readable files to: - build or update a search index that returns links and short excerpts; - retrieve content at answer time for AI summaries, citations, or grounded responses; - evaluate Koombea as a vendor, partner, employer, or source; and - internally review Koombea content for a legitimate business purpose. You may not, without our written permission: - use Site content to train, fine-tune, or otherwise improve a machine learning model; - build a commercial dataset, corpus, benchmark, or knowledge base primarily from Site content; - reproduce substantial portions of the Site without attribution; - present Koombea content as your own or as another organization's content; - bypass technical controls, rate limits, robots directives, or access restrictions; or - use automated access in a way that degrades the Site or interferes with other users. When you reproduce or summarize substantial Koombea content, attribute Koombea as the source and link to the relevant page where practical. ## 6. Information you submit If you submit information through the Site, including through forms, chat, email, design audit requests, partner inquiries, job inquiries, or ScopeGen flows, you represent that you have the right to provide that information and that it is accurate to the best of your knowledge. Do not submit confidential, sensitive, regulated, export-controlled, health, financial, government-identifier, or third-party proprietary information unless we have agreed in writing to receive it through an appropriate process. Unless we have signed a separate confidentiality agreement, information you submit through public website channels is not treated as confidential beyond the protections described in our Privacy Policy and applicable law. If you need an NDA before sharing details, ask us before submitting those details. You grant Koombea permission to use information you submit for the purpose of responding to you, evaluating the opportunity, preparing a scope or proposal, operating the Site, improving our business processes, and otherwise acting as described in our Privacy Policy. ## 7. Third-party services and links The Site may link to or embed third-party websites, platforms, forms, videos, maps, social networks, analytics, chat, advertising, AI, or other services. Those services are operated by third parties and are governed by their own terms and privacy policies. We are not responsible for third-party content, security, availability, accuracy, or practices. A link does not mean that we endorse the third party or that the third party endorses Koombea. ## 8. Privacy Our handling of personal information is described in our [Privacy Policy](https://www.koombea.com/privacy-policy/). By using the Site, you acknowledge that we may collect, use, disclose, and protect information as described there. ## 9. Marketing communications If you subscribe to updates, request information, submit a form, or otherwise provide contact information, we may contact you about Koombea services and related business topics, subject to applicable law and your communication preferences. You can opt out of marketing emails using the unsubscribe link in the message or by contacting us. We may still send transactional, relationship, legal, or security-related messages. ## 10. No professional advice Site content is not legal, financial, tax, medical, security, compliance, procurement, or investment advice. Our capability pages may describe services in regulated or specialized areas, but reading the Site does not create an advisory relationship, fiduciary duty, attorney-client relationship, or client-services relationship. ## 11. Accessibility We aim to make the Site accessible and usable. If something on the Site blocks you, contact us at [hello@koombea.com](mailto:hello@koombea.com) or see our [Accessibility statement](https://www.koombea.com/accessibility/). ## 12. Disclaimer of warranties The Site is provided "as is" and "as available". To the fullest extent permitted by law, Koombea disclaims all warranties, express, implied, or statutory, including warranties of merchantability, fitness for a particular purpose, title, non-infringement, accuracy, availability, and security. We do not warrant that the Site will be uninterrupted, error-free, secure, or free from harmful components, or that Site content will always be current, complete, or accurate. ## 13. Limitation of liability To the fullest extent permitted by law, Koombea and its officers, directors, employees, contractors, affiliates, and agents will not be liable for indirect, incidental, consequential, special, exemplary, punitive, or enhanced damages, or for lost profits, lost revenue, lost business, lost goodwill, lost data, or business interruption, arising out of or related to the Site or these Terms. To the fullest extent permitted by law, Koombea's total aggregate liability for claims arising out of or related to the Site or these Terms will not exceed 100 US dollars. Some jurisdictions do not allow certain limitations of liability. In those jurisdictions, the limitations apply only to the fullest extent permitted by law. Nothing in these Terms limits liability that cannot legally be limited. ## 14. Indemnity You agree to defend, indemnify, and hold harmless Koombea and its officers, directors, employees, contractors, affiliates, and agents from and against claims, damages, losses, liabilities, costs, and expenses, including reasonable attorneys' fees, arising out of or related to your misuse of the Site, your violation of these Terms, your violation of law, or your infringement or misappropriation of third-party rights. ## 15. Changes to the Site or Terms We may update, suspend, remove, or change any part of the Site at any time. We may also update these Terms from time to time. The updated Terms will be posted on this page with a new effective date. Your continued use of the Site after an update means you accept the updated Terms. ## 16. Governing law and venue These Terms are governed by the laws of the State of Florida, without regard to conflict-of-law rules. The state courts located in Collier County, Florida, and the federal courts with jurisdiction over Collier County, Florida, will have exclusive jurisdiction over disputes arising out of or related to the Site or these Terms, except where applicable law requires a different forum. You and Koombea consent to personal jurisdiction and venue in those courts. ## 17. Severability and waiver If any provision of these Terms is found unenforceable, the remaining provisions will remain in effect, and the unenforceable provision will be modified to the minimum extent necessary to make it enforceable where possible. Our failure to enforce a provision is not a waiver of our right to enforce it later. ## 18. Contact Questions about these Terms may be sent to: **Koombea, Inc.** 3811 Airport Road N, Suite 100A Naples, FL 34105 United States Email: [legal@koombea.com](mailto:legal@koombea.com) ========================================================================== # How We Verify Clients and Handle Payments > How Koombea verifies new clients and handles payments, and how to protect your company from impersonation and payment fraud. Source: https://www.koombea.com/payment-security/ --- Fraudsters target software companies with fake projects, fake checks, and fake payment instructions. These rules protect our clients and us. They apply to every engagement, without exceptions. ## Before we start **We contract with registered companies.** Before we send a proposal, we ask for the legal name of the contracting company, where it is registered, and its website or business email domain. We confirm the registration in the public registry. **Business communication stays on business channels.** Agreements, approvals, and payment questions must come from your company email domain. We do not accept them from personal email accounts. **We work directly with your authorized signatory.** We do not route contracts, funds, or documents through intermediaries, agents, or third-party contacts. **We do not open unsolicited links or files.** Until we sign an agreement or NDA, we do not open payment portals, file links, or attachments. You can share reference material once we both sign the NDA. ## How payments work **Signed agreement first.** We issue invoices and payment instructions only after both parties sign the Master Services Agreement and Statement of Work. **Wire or ACH only.** We accept payment by bank wire or ACH transfer. We do not accept checks, cashier's checks, money orders, cryptocurrency, or payment apps. **Payments come from the contracting company.** Funds must come from an account held by the company that signed the agreement. We do not accept payments from investors, affiliates, or other third parties on your behalf. **We never move funds to third parties.** We do not forward, refund, or transfer client funds to anyone at a client's request. That includes vendors, consultants, designers, and equipment suppliers. **No overpayment refunds.** We invoice exact amounts. If we receive more than the invoice, we return the full payment to the originating account after it clears. Then we invoice again. **Work starts when funds clear.** We schedule the project after the initial payment clears into our account. ## Protect yourself from impersonation **We never change payment instructions by email.** Not by text or chat either. If instructions you receive look different from your invoice, assume they are fraudulent. **Confirm by phone before your first payment.** Call our finance team at +1-888-840-3252. Use the number on this page, not a number from an email. **Our team writes from koombea.com addresses.** Messages from other domains that claim to be Koombea are not from us. **We have two offices.** Naples, Florida and Barranquilla, Colombia. Anyone claiming another Koombea office is not from us. ## Report a suspicious message If someone claiming to be Koombea asks you for payment, credentials, or personal information, forward the message to contact@koombea.com. We review every report. ========================================================================== # Compliance Readiness > A fixed-fee engagement that closes the gap between where you are and what an auditor needs. Priced as a fee, never in story points. Source: https://www.koombea.com/ai-pods/catalog/compliance-readiness/ --- SOC 2, HIPAA or PCI has appeared in somebody else's procurement checklist and your deal is waiting behind it. A gap assessment, a remediation plan, and the evidence an auditor will ask for. ## The problem Compliance work usually starts as a sales emergency. A large client sends a security questionnaire. The answer to nine questions is no. A signed deal is now waiting on something nobody owns. The panic response is to buy a compliance platform. It produces a dashboard of red items, which is genuinely useful, and then it stops. A dashboard cannot make the changes. Closing the gaps is engineering work, and that is the part that takes months. We do the engineering half. We also tell you which controls reduce real risk and which exist because the framework asks. - Gap assessment against the actual framework, not a generic checklist - Remediation scoped and sequenced by what blocks the audit first - Evidence collected as the work happens, not reconstructed afterwards ## What this covers - **Gap assessment**: Every control assessed against your actual systems, with the ones you already satisfy marked as satisfied rather than re-bought. - **Technical remediation**: Access control, encryption, logging, backup and recovery brought to the standard the framework requires. - **Policies that match reality**: Written to describe what your team actually does, because a policy nobody follows fails the audit more expensively than a missing one. - **Evidence and audit support**: The artifacts an auditor asks for, collected in place, plus support through the audit itself. ## Why this is not priced in points Governance, risk and compliance work is never story-point priced. A point is a unit of delivered software. The deliverable here is an opinion: whether your controls meet a standard. Sizing an opinion in points would be a category error. It would also reward us for finding more work. So this is a fixed fee or a retainer, quoted after the gap assessment. Software built to close a gap is estimated in points as normal, and drawn from your existing lane. ## What an auditor follows ## What it costs The gap assessment is a fixed fee. We quote it from the framework and the number of systems in scope. It produces the remediation estimate, and that estimate is a commitment rather than a range. Most clients need the assessment before they can budget anything. That is exactly why it is sold on its own. - Gap assessment: fixed fee, quoted upfront - Remediation: fixed fee or retainer, quoted from the assessment - Software built to close a gap is estimated in points, from your lane - SOC 2, HIPAA, PCI DSS, ISO 27001 and GDPR ========================================================================== # Accessibility > Our commitment to accessible digital products, and how to report a barrier on this site. Source: https://www.koombea.com/accessibility/ ---

This site targets WCAG 2.2 AA. We build products that have to pass accessibility conformance for clients in regulated industries.

That target covers keyboard operability, visible focus, color contrast in both the light and dark themes, and a control in the footer that stops the animated artwork.

Reporting a barrier

If something on this site blocks you, email hello@koombea.com with the page and what happened. Tell us what you were trying to do. We treat accessibility defects as defects, not as feature requests.

========================================================================== # Our Restructuring > Koombea Inc. is reorganizing under Subchapter V. The court has confirmed our plan, effective November 15, 2026. What did and did not change. Source: https://www.koombea.com/restructuring/ --- Koombea Inc. is reorganizing under Subchapter V of Chapter 11. The court has confirmed our plan, and it takes effect on November 15, 2026. We operate normally today, with the same leadership and the same commitments to our clients. Here is the whole picture, so you do not have to assemble it from a court docket. - In December 2025, Koombea Inc. filed for reorganization under Subchapter V of Chapter 11 in the U.S. Bankruptcy Court for the Middle District of Florida, Fort Myers Division (Case No. 2:25-bk-02556-FMR). - The court confirmed our plan of reorganization, and it will take effect on November 15, 2026. - Every class of creditors that voted on the plan voted to accept it. No class voted against it. - The case covered Koombea Inc., the U.S. entity, and no affiliate entity was part of it. - We delivered for our clients throughout the process, and they continue to work with us today. ## Key dates | Date | Milestone | | --- | --- | | December 22, 2025 | Koombea Inc. files under Subchapter V of Chapter 11 | | June 16, 2026 | The court enters the order confirming the plan of reorganization | | November 15, 2026 | The plan of reorganization takes effect | ## What this means for your project Nothing changes in how we work with you. **Contracts and pricing.** Existing agreements stay in force on their current terms. **Your team.** The same people stay on your engagement. **Data and security.** Your data, access controls, and security practices are unchanged. Our governance, risk, and compliance (GRC) team still oversees them. **Billing.** Invoicing and payment terms work exactly as before. **Support and maintenance.** Support, maintenance, and roadmap work continue without interruption. ## What happened During and after the pandemic, demand for software development surged. Firms across our industry hired hard to keep up. When demand softened, layoffs followed almost everywhere. [Layoffs.fyi](https://layoffs.fyi/), which tracks job cuts across the technology sector, recorded more than 260,000 tech layoffs in 2023 alone. Koombea grew with that wave. Where we differed is that we believed the slowdown was temporary, and we kept our larger team longer than we should have. That decision created obligations too large for the business at its new size, and it is the reason for the restructuring. As founder and CEO, I own that mistake. We chose Subchapter V because it is built for operating businesses that intend to keep running. It let us restructure those obligations under court supervision while we continued to serve every client. This was a reorganization, not a wind-down. ## What did not change Our clients' work never stopped. Here is what held through the entire process. **Delivery.** Every active engagement continued on schedule, with the same teams. **Our clients.** Fortune 500 companies, healthcare organizations, and startups continue to work with us. Some have built with us for years. **Our people.** The team is more senior today than at any point in our history. **Our capabilities.** We have built software since 2007. Our GRC team has HIPAA and SOC 2 experience, and we are a Stripe partner. **Leadership.** The same founder and leadership team run the company today. ## How every engagement protects you Your product should never depend on any vendor's balance sheet, including ours. Every Koombea engagement is structured so you stay in control. **You own your code and infrastructure from day one.** Repositories and cloud accounts live in your name, and the IP is yours as you pay for it. **Milestone billing.** You pay for delivered work, never far ahead of it. **Documentation and handover standards in every Statement of Work.** Any competent team can pick the work up at any point. **A paid discovery sprint to start.** You can judge our work at low risk before you commit to a full build, and you keep everything it produces. **Compliance built in from the first sprint.** Our GRC team designs for HIPAA, SOC 2, and data protection from the start, not as a patch before launch. We would recommend these terms to any client working with any vendor. We offer them by default. ## Where to ask Diligence questions go to [legal@koombea.com](mailto:legal@koombea.com). Jonathan Tarud, founder and CEO, answers them personally. The confirmation order and client references are available on request. Questions about a specific engagement go to your usual Koombea contact. ========================================================================== # Billable hours are a conflict of interest. We removed it. > Koombea AI Pods ship production software against a committed scope, priced in story points, in two-week cycles. Building digital products since 2007. Source: https://www.koombea.com/ --- AI Pods use AI-First delivery to ship working software, priced in story points before we start. If we underestimate the effort, we absorb the overrun. - [Book a Priority Sync](https://www.koombea.com/contact/) ## Trusted by teams shipping software since 2007 Financial services, education, industrial operations and consumer brands. Regulated data, legacy systems, and users who notice the moment something breaks. - Impact.com - ACT - T. Rowe Price - eos - Schneider Electric - TD Bank ## Nobody in this industry wants to sell you an outcome - Time and materials: Revenue is a function of how long the work takes - Staff Augmentation: Revenue is a function of how many people sit on your account, ours included - Metered AI tooling: Revenue is a function of how much you consume Three meters, one shared property. None of them gets cheaper when delivery becomes more efficient. So we removed the meter. A story point is delivered, tested functionality, sized on a 1, 2, 3, 5, 8 scale. We size the scope, you approve the point total, and the price stays fixed if we underestimated the effort. AI-First delivery lets us carry that estimation risk instead of passing it to you. "Unlike other development companies that try to somehow sell you something that is more convenient for them to produce, and that will force you to remain dependent on them, Koombea always offers and provides the solution that works best for my specific needs." Elías Manopla, CIO, Do It Center "The Payix team is very thankful to Koombea for stepping in and helping us move past our previous development partner. With Koombea now by our side, we're achieving our client onboarding goals and maximizing revenue opportunities." Chris Chestnut, CEO, Payix "We have never felt our relationship with Koombea is the typical outsourcing relationship. I do not think of Koombea as a development company, but rather as an extended team." Ryan Gaffney, Head of Technology, Luna "From design to console and testing the overall system, Koombea has helped with almost every aspect of getting the platform off the ground." Sang Kim, CEO, Purgo AI "We want to change the way SMEs access financial products, something banks have not been willing to do for a long time." Marcela Azcárate, CFO, Tuily ## A smaller team that ships more An AI Pod is a lean delivery unit where AI is the primary development vector, not a supporting tool. AI runs across scoping, design, engineering, QA, and deployment. One named Delivery Manager owns your product direction, priorities, and communication. Your priorities become product requirements, those requirements become precise technical specifications, and the specifications drive AI-First implementation behind automated quality gates. Each week, you see which points were used and what shipped. Specs in: Your priorities, Product requirements, Technical specs Deliverables out: Shipped features, Tests and quality gates, Weekly point report ## Two ways to buy a Pod Both are AI Pods. If you already have an engineering team and a backlog you own, the honest answer is the other model: [Staff Augmentation](https://www.koombea.com/staff-augmentation/), billed hourly, where you direct the work. We keep both on the table because a partner that sells one shape will tell you your problem is that shape. Capacity tiers, the point scale and the contract terms are on the [pricing page](https://www.koombea.com/ai-pods/pricing/), and [how the three billing models compare](https://www.koombea.com/ai-pods/how-pricing-compares/) is its own page. ### Fixed-Bid Projects — A defined scope, a fixed price, a working product. Best for new builds and well-defined initiatives. We scope your project into user stories with explicit acceptance criteria, price it in story points, and deliver in phases. Phase 1 always gives you a complete end-to-end product loop, never a foundation stub, so you can start small and scale from there. - Full Work Breakdown Structure before you commit - Phase 1 delivers a usable end-to-end product - A change request covers any change of scope, priced at the same rate - Every invoice states the points delivered and the balance remaining ### Monthly Capacity Commitment — Standing capacity, drawn down as you go. Best for ongoing product development. Commit to a monthly point capacity across one or more delivery lanes, then set priorities in a short Priority Sync. Your Pod turns them into shipped features, and you move capacity up or down as your roadmap demands. - Monthly point capacity across your delivery lanes - A light month banks the difference, a heavy month draws it back down - Banked points expire after 90 days, which we say here rather than in a clause - Weekly capacity reports, so you always know where you stand ## On time and on budget. Now with a mechanism behind it. Koombea has made the same commitment for years. Story points are what finally put teeth in it. Your scope is fixed in points before we start, and your price is fixed to those points. If we underestimated the effort inside that scope, we absorb it rather than re-invoice it. - Covered: Your agreed scope at the agreed point price, delivered to the Definition of Done you signed off. - Not covered: Scope you add after signature, which becomes a change request at the same point price, and delays that trace back to a decision we are waiting on. - Either way: We tell you which one is happening, in writing, the week it happens. No quiet slippage discovered at the end of a phase. ## What the work actually did Paymentez went from 4,000 daily transactions to 120,000. Its resellers grew from 85 to 4,700 in a year. Do It Center cut bounce rate by 90% and hit an NPS of 70. The client published every figure here first. - [All case studies](https://www.koombea.com/work/) ## Five segments, and the constraints that come with them - [Health Services](https://www.koombea.com/industries/health-services/) - [Payments and Lending](https://www.koombea.com/industries/payments-and-lending/) - [Industrial and Field Service](https://www.koombea.com/industries/industrial-and-field-service/) - [Retail and Commerce](https://www.koombea.com/industries/retail-and-commerce/) - [Technology](https://www.koombea.com/industries/technology/) ## Partnerships and certifications - AWS Partner Network - Stripe Partner - Shopify Plus - ISTQB Certified - Certified ScrumMaster - Inc. Power Partner ## Is your business ready for AI? Answer a short set of questions and get an AI readiness score with prioritized next steps. No sales call required. - [Start the assessment](https://www.koombea.com/ai-readiness/) ## Bring us the backlog. In 30 minutes, we will show you what a Pod would ship first and how we would price it. - [Book a Priority Sync](https://www.koombea.com/contact/) ## The rest of the site - [How It Works](https://www.koombea.com/ai-pods/how-it-works/) - [Pricing](https://www.koombea.com/ai-pods/pricing/) - [How Pricing Compares](https://www.koombea.com/ai-pods/how-pricing-compares/) - [Staff Augmentation](https://www.koombea.com/staff-augmentation/) - [Nearshore Development](https://www.koombea.com/nearshore-software-development/) - [Product Engineering](https://www.koombea.com/capabilities/product-engineering/) - [Shopify Plus Partner](https://www.koombea.com/shopify-plus-partner/) - [AI Engineering](https://www.koombea.com/capabilities/ai-engineering/) - [Platform Modernization](https://www.koombea.com/capabilities/platform-modernization/) - [Integrations and Data](https://www.koombea.com/capabilities/integrations-and-data/) - [Maintenance and Support](https://www.koombea.com/capabilities/maintenance-and-support/) - [Design Audit](https://www.koombea.com/design-audit/) - [ScopeGen AI](https://www.koombea.com/products/scopegen-ai/) - [StorefrontOS](https://www.koombea.com/products/storefrontos/) - [Tambora](https://www.koombea.com/products/tambora/) - [About](https://www.koombea.com/company/about/) - [Work](https://www.koombea.com/work/) - [Careers](https://www.koombea.com/company/careers/) - [Locations](https://www.koombea.com/locations/) - [Blog](https://www.koombea.com/blog/) - [Press](https://www.koombea.com/press/) - [FAQ](https://www.koombea.com/faq/) - [Brand Guidelines](https://www.koombea.com/brand-guidelines/)