# Rokad — Full Published Content # Technology Services ## [Service] Software development Canonical URL: https://rokad.co/en/services/software-development > Production-ready software engineered around users, operations, security, integrations, and long-term ownership. Rokad designs, builds, modernises, and operates custom software across SaaS, enterprise applications, ecommerce, marketplaces, internal tools, APIs, and connected business systems. Engagements can begin at product discovery, an existing codebase, or a defined transformation requirement. ### Capabilities - Product discovery and technical planning - Software architecture and system design - Frontend, backend, API, and integration engineering - Payments, identity, permissions, notifications, and administration - Data migration and legacy modernisation - Testing, cloud deployment, observability, and managed support ### Challenges - **A product must move beyond an MVP:** Replace fragile assumptions and shortcuts with an architecture, operating model, and delivery foundation suitable for real customers. - **Operations depend on disconnected tools:** Consolidate manual workflows, duplicate data, and inconsistent processes into an integrated software system. - **Legacy software restricts growth:** Modernise technology, interfaces, infrastructure, and delivery practices without losing critical business behaviour or data. ### Service scope - **Discovery and architecture:** Requirements, user flows, domain modelling, build-versus-buy decisions, integration mapping, delivery planning, and risk reduction. - **Product engineering:** Frontend, backend, database, API, workflow, administrative, and integration development under one accountable team. - **Launch and operation:** Testing, migration, deployment, monitoring, documentation, knowledge transfer, support, and continuous improvement. ### Use cases - **Launch a new software product:** Take a validated opportunity from discovery through a secure, customer-ready, production deployment. - **Build an operational platform:** Replace spreadsheets and fragmented applications with software designed around the organisation's actual workflows. - **Modernise an existing system:** Improve maintainability, performance, security, usability, and infrastructure while protecting critical data and operations. - **Extend an existing engineering team:** Add accountable product, architecture, frontend, backend, integration, or platform capacity to an active roadmap. ### Delivery process - **Discover:** Clarify the business objective, users, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, delivery plan, integrations, security controls, and operating model before implementation. - **Build and validate:** Deliver in controlled increments with review, automated testing, documentation, and stakeholder validation. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence. ### Engineering standards - **Security by design:** Threats, permissions, secrets, data boundaries, dependencies, and recovery requirements are addressed during architecture and delivery. - **Production quality:** Testing, code review, observability, deployment controls, documentation, and rollback planning are treated as delivery requirements. - **Long-term ownership:** The client receives maintainable source code, operating knowledge, technical documentation, and a practical path for future development. ### Deliverables - Product and technical discovery package - Architecture, data model, and integration plan - Production application and source code - Automated tests and quality evidence - Cloud and deployment configuration - Technical, API, and operating documentation - Launch, migration, and handover support ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded engineering:** Specialist engineers working inside an existing product, technology, or operations team. - **Managed evolution:** Ongoing maintenance, reliability, security, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad take an existing MVP to production?** Yes. We audit the product, architecture, code, infrastructure, security, data, and operating assumptions, then define the shortest controlled path to production readiness. - **Can Rokad work with our existing engineering team?** Yes. We can own a defined workstream, provide specialist engineers, lead architecture, or operate as an integrated product-development team. - **Who owns the source code and intellectual property?** Client-specific source code and agreed deliverables are transferred according to the engagement contract. Any third-party or pre-existing components are identified explicitly. - **Can Rokad maintain the product after launch?** Yes. Managed support can include monitoring, security updates, incident response, performance, feature delivery, release management, and roadmap execution. - **How are scope changes handled?** Scope, assumptions, dependencies, and acceptance criteria are documented. Material changes are evaluated for delivery, cost, and risk impact before being approved. --- ## [Service specialisation] SaaS development Canonical URL: https://rokad.co/en/services/software-development/saas > Rokad designs and develops customer-ready SaaS platforms with multi-tenancy, subscriptions, administration, integrations, observability, and long-term product operations. A commercial SaaS product is more than an application interface. Rokad engineers the product, tenant model, identity, billing, onboarding, administration, analytics, integrations, support tooling, and cloud operations required to acquire and serve customers reliably. ### Designed for - **Founders with a validated product opportunity:** Move from concept, prototype, or early MVP to a product that can onboard, bill, support, and retain real customers. - **Companies productising internal software:** Convert a single-organisation tool into a secure multi-tenant platform with repeatable onboarding and commercial operations. - **SaaS teams modernising for growth:** Improve architecture, tenancy, reliability, permissions, billing, observability, and delivery speed without disrupting customers. ### Challenges - **The MVP cannot support paying customers:** Critical capabilities such as tenant isolation, permissions, billing, administration, support, and operational visibility are missing or fragile. - **Growth creates architectural and operational risk:** Customer variation, data volume, integrations, permissions, and releases make the product increasingly difficult to operate. - **Commercial workflows remain manual:** Sales handoff, onboarding, provisioning, subscription changes, usage, support, and retention are disconnected from the product. ### Capabilities - Multi-tenant architecture and tenant isolation - Authentication, organisations, teams, roles, and permissions - Subscription billing, usage metering, plans, trials, and entitlements - Customer onboarding, provisioning, invitations, and lifecycle workflows - Administrative consoles, support tooling, audit trails, and feature controls - Notifications, analytics, integrations, APIs, and webhooks - Cloud infrastructure, observability, security, backup, and release automation ### Solution components - **Customer product:** The workflows, interfaces, collaboration, data, and outcomes customers purchase the platform to access. - **Commercial system:** Plans, trials, billing, usage, entitlements, invoices, subscription changes, and customer lifecycle events. - **Operator control plane:** Tenant administration, support actions, auditability, feature controls, issue diagnosis, and operational reporting. - **Platform foundation:** Identity, data isolation, integrations, background work, observability, security, deployment, backup, and recovery. ### Use cases - **B2B workflow SaaS:** Digitise a specialised organisational workflow with collaboration, approvals, reporting, integrations, and account-level controls. - **Vertical SaaS:** Build software around the terminology, operations, regulation, and integrations of a defined industry segment. - **AI-native SaaS:** Combine product workflows with governed generation, retrieval, agents, evaluation, usage controls, and model economics. - **Internal platform commercialisation:** Transform proven internal software into a configurable product that can securely serve many organisations. ### Architecture and integration - **Tenancy model:** Choose shared, isolated, or hybrid data and infrastructure patterns based on security, scale, customisation, and economics. - **Billing and entitlement boundary:** Keep plans, subscriptions, usage, access, limits, and product capabilities consistent across commercial and technical systems. - **Integration platform:** Expose reliable APIs, webhooks, connectors, background jobs, and event flows for customer and partner ecosystems. ### Quality and control - **Secure engineering:** Permissions, data boundaries, secrets, dependencies, threat scenarios, and recovery requirements are addressed throughout delivery. - **Production readiness:** Testing, observability, performance, deployment controls, rollback planning, and operating documentation are included in the definition of done. - **Maintainable ownership:** The client receives structured source code, technical documentation, operating knowledge, and a practical path for future development. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - Product discovery and SaaS architecture package - Production multi-tenant application and source code - Identity, permissions, billing, onboarding, and administration - Automated tests, deployment pipeline, and infrastructure configuration - Observability, backup, recovery, and security controls - API, technical, product-operation, and handover documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad take an existing SaaS MVP to production?** Yes. We audit the code, architecture, tenancy, data, security, billing, infrastructure, product operations, and roadmap, then define a controlled production-readiness plan. - **How do you approach multi-tenant architecture?** We select shared, isolated, or hybrid patterns based on data sensitivity, customer requirements, scale, customisation, operational complexity, and cost. Tenant boundaries are enforced across data, permissions, background work, caching, and observability. - **Can you implement subscriptions and usage-based billing?** Yes. We can integrate plans, trials, subscriptions, metering, entitlements, invoices, tax-related provider capabilities, payment events, and account lifecycle workflows. - **Can existing customers and data be migrated?** Yes. Migration planning covers mapping, cleansing, validation, rehearsal, cutover, rollback, customer communication, and post-migration verification. - **Do you provide post-launch product development?** Yes. Rokad can maintain the platform, operate cloud and releases, resolve incidents, improve reliability, and continue delivering the product roadmap. --- ## [Service specialisation] Ecommerce development Canonical URL: https://rokad.co/en/services/software-development/ecommerce > Rokad builds ecommerce systems that connect customer experience with payments, inventory, orders, fulfilment, customer operations, and business intelligence. Effective commerce software must coordinate the entire transaction lifecycle. Rokad develops storefronts, catalogues, checkout, B2B ordering, marketplaces, order management, inventory, fulfilment, returns, customer systems, analytics, and integrations using custom, platform, or headless approaches. ### Designed for - **Brands launching or scaling direct commerce:** Create a high-performance buying experience connected to the operational systems required to fulfil and support demand. - **B2B sellers digitising complex ordering:** Support account pricing, quotations, approvals, credit, repeat orders, catalogues, and buyer-specific workflows. - **Retailers modernising fragmented commerce:** Connect stores, ecommerce, inventory, POS, ERP, warehouse, fulfilment, returns, and customer data. ### Challenges - **The storefront is disconnected from operations:** Orders, inventory, fulfilment, customer service, finance, and marketing depend on manual reconciliation or inconsistent data. - **A standard platform cannot support the business model:** Pricing, catalogue, B2B, marketplace, regional, fulfilment, or integration requirements exceed template-level configuration. - **Performance and conversion decline as complexity grows:** Third-party scripts, catalogue scale, search, personalisation, content, and checkout behaviour make the experience slow or unreliable. ### Capabilities - Storefront, catalogue, search, merchandising, and product content - Cart, checkout, payments, promotions, tax, and pricing rules - Inventory, order management, fulfilment, shipping, returns, and refunds - B2B accounts, quotations, approvals, credit, and contract pricing - Marketplace, multi-vendor, commission, payout, and operator workflows - ERP, POS, CRM, warehouse, marketing, analytics, and marketplace integrations - Headless commerce, replatforming, migration, performance, and managed operations ### Solution components - **Buying experience:** Discovery, catalogue, search, content, merchandising, cart, checkout, account, and post-purchase interfaces. - **Commerce engine:** Products, variants, prices, promotions, taxes, inventory, orders, payments, refunds, and transaction rules. - **Operational workflows:** Fulfilment, warehouse, shipping, returns, customer service, finance, vendor, and exception management. - **Integration and intelligence:** ERP, POS, CRM, analytics, marketing, marketplaces, logistics, search, recommendations, and business reporting. ### Use cases - **Direct-to-consumer platform:** Deliver a differentiated brand and buying experience with reliable payments, fulfilment, retention, and content operations. - **B2B ordering portal:** Digitise complex account, product, pricing, quotation, approval, payment, and repeat-order workflows. - **Multi-vendor marketplace:** Coordinate seller onboarding, listings, transactions, commission, fulfilment, disputes, payouts, and operator controls. - **Commerce modernisation:** Replatform or decouple an ageing store while preserving customer, product, order, content, and search equity. ### Architecture and integration - **Platform strategy:** Choose configured SaaS, headless commerce, composable services, or custom development based on differentiation and operating economics. - **System of record:** Define authoritative ownership for products, prices, inventory, customers, orders, fulfilment, and financial events. - **Transaction integrity:** Design idempotent payment, inventory, order, refund, webhook, and reconciliation flows for reliable commerce operations. ### Quality and control - **Secure engineering:** Permissions, data boundaries, secrets, dependencies, threat scenarios, and recovery requirements are addressed throughout delivery. - **Production readiness:** Testing, observability, performance, deployment controls, rollback planning, and operating documentation are included in the definition of done. - **Maintainable ownership:** The client receives structured source code, technical documentation, operating knowledge, and a practical path for future development. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - Commerce discovery and platform recommendation - Production storefront, customer account, and checkout - Catalogue, order, inventory, fulfilment, and return workflows - Payment, ERP, POS, CRM, logistics, and analytics integrations - Migration, redirect, test, performance, and launch plan - Operating, support, and commerce-administration documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Should we use a platform, headless commerce, or a custom system?** The decision depends on differentiation, catalogue and transaction complexity, B2B or marketplace requirements, integrations, content, performance, team capabilities, and total ownership cost. We document the trade-offs before recommending an approach. - **Can Rokad migrate an existing store without losing data or SEO?** Yes. We plan product, customer, order, content, URL, metadata, redirect, analytics, and integration migration with rehearsal, validation, rollback, and post-launch monitoring. - **Can the platform connect to ERP, POS, warehouse, or CRM systems?** Yes. We design reliable APIs, events, scheduled synchronisation, reconciliation, error handling, and ownership rules between commerce and operational systems. - **Can you build B2B or marketplace functionality?** Yes. Capabilities can include account pricing, quotations, approvals, credit, sellers, commissions, payouts, moderation, disputes, and operator workflows. - **Do you support high-volume sale periods?** Yes. Capacity, caching, queues, payment behaviour, inventory contention, observability, incident response, and rollback planning can be validated before major demand events. --- ## [Platform service] Shopify development services Canonical URL: https://rokad.co/en/services/software-development/ecommerce/shopify Platform: Shopify > Rokad builds, extends, migrates, and operates Shopify and Shopify Plus commerce across storefronts, apps, checkout, B2B, headless architecture, and enterprise integrations. Shopify supports rapid commerce delivery, but durable implementations require clear boundaries between theme, app, Functions, checkout extensions, headless storefront, data, and external systems. Rokad designs the commerce architecture, develops platform-native extensions, integrates operations, migrates data, and establishes release and support practices. ### Designed for - **Brands launching or redesigning a Shopify store:** Create a high-performing storefront, product experience, content system, checkout journey, analytics, and operational foundation. - **Shopify Plus merchants with complex requirements:** Implement B2B, multi-market, checkout extensions, custom apps, ERP, fulfilment, customer, and merchandising workflows. - **Commerce teams migrating from another platform:** Move catalogue, customers, orders, redirects, content, subscriptions, integrations, and operating workflows with controlled validation. ### Implementation risks - **The theme carries too much business logic:** Pricing, eligibility, data, integrations, scripts, and custom behaviour become difficult to test, upgrade, and operate. - **Apps create overlapping cost and performance impact:** Third-party scripts, duplicated capabilities, data access, checkout behaviour, and subscriptions are not governed as one system. - **Commerce operations remain fragmented:** Products, inventory, orders, fulfilment, returns, customer service, finance, and analytics drift across external systems. ### Platform capabilities - Shopify theme architecture, Online Store 2.0 sections, components, accessibility, and performance - Shopify Plus, B2B, Markets, multi-store, catalogue, customer, pricing, and operational design - Custom Shopify apps, Admin API, Storefront API, webhooks, extensions, and embedded administration - Checkout UI extensions, Shopify Functions, customer-account extensions, and web pixels - Hydrogen and headless Shopify storefronts, customer accounts, search, caching, and deployment - ERP, PIM, WMS, CRM, fulfilment, payments, tax, subscriptions, support, and analytics integration - Migration, redirects, data validation, testing, release, monitoring, maintenance, and managed improvement ### Implementation system - **Storefront system:** Theme or headless architecture, content, search, collections, product data, merchandising, accessibility, performance, and analytics. - **Shopify extension layer:** Apps, Functions, checkout and account extensions, web pixels, webhooks, permissions, billing, and platform lifecycle. - **Commerce operations:** Catalogue, inventory, orders, fulfilment, returns, subscriptions, customer service, finance, tax, and reconciliation. - **Migration and operation:** Data, redirects, integrations, deployment, monitoring, app governance, support, release, and continuous optimisation. ### Use cases - **Shopify Plus replatforming:** Migrate enterprise commerce while preserving customer, catalogue, order, SEO, subscription, and operational continuity. - **Custom Shopify application:** Build merchant, customer, fulfilment, pricing, product, workflow, or integration capabilities not met by standard apps. - **Shopify B2B implementation:** Support companies, locations, buyers, catalogues, pricing, payment terms, permissions, orders, and ERP integration. - **Headless Shopify storefront:** Develop a differentiated frontend while preserving Shopify commerce, checkout, customer, and operational capabilities. ### Architecture - **Platform-native extension first:** Use supported APIs, Functions, checkout extensions, account extensions, webhooks, and app surfaces instead of brittle theme workarounds. - **Commerce records have explicit owners:** Define authority and synchronisation for product, price, inventory, customer, order, fulfilment, refund, and subscription data. - **Headless only with a clear advantage:** Use Hydrogen or custom headless delivery when experience, channel, performance, composition, or organisational needs justify added operation. ### Quality and governance - **Transaction integrity:** Pricing, inventory, tax, payment, order, fulfilment, refund, promotion, and customer state remain consistent across systems. - **Performance and conversion:** Storefront rendering, search, product data, checkout, third parties, analytics, and mobile behaviour are measured and optimised. - **Upgrade-safe extensibility:** Themes, extensions, APIs, webhooks, custom services, and platform capabilities are used with clear ownership and lifecycle planning. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Shopify commerce, theme, app, data, integration, and operational assessment - Storefront, app, checkout, B2B, headless, and integration architecture - Production theme, custom app, extensions, Functions, or Hydrogen storefront - Catalogue, order, customer, inventory, fulfilment, and enterprise integrations - Migration, redirect, test, release, analytics, performance, and monitoring controls - Merchant, developer, operator, support, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad build a custom Shopify app?** Yes. We can develop embedded or service applications using supported APIs, webhooks, extensions, authentication, billing, data, and merchant interfaces. - **Can Rokad migrate a store to Shopify?** Yes. We plan catalogue, variants, customers, orders, content, redirects, subscriptions, reviews, integrations, analytics, and operational transition. - **Should we use a theme or headless Shopify?** The choice depends on experience requirements, content, channels, team capability, integrations, performance, deployment, preview, and total ownership cost. - **Can Rokad maintain a Shopify store after launch?** Yes. Managed support can cover themes, apps, integrations, checkout, performance, analytics, releases, incidents, platform changes, and conversion improvements. --- ## [Platform service] WooCommerce development services Canonical URL: https://rokad.co/en/services/software-development/ecommerce/woocommerce Platform: WooCommerce > Rokad builds, extends, migrates, secures, and maintains WooCommerce stores with custom themes, plugins, integrations, subscriptions, and performance engineering. WooCommerce provides deep ownership and extensibility through WordPress, but reliability depends on disciplined plugin selection, custom-code boundaries, hosting, caching, updates, security, data, checkout, and operational integration. Rokad engineers the platform as a maintainable commerce application rather than an unmanaged plugin collection. ### Designed for - **Businesses requiring flexible owned commerce:** Build custom product, checkout, content, subscription, membership, marketplace, or operational workflows on WordPress. - **Merchants with unstable WooCommerce stores:** Improve performance, checkout reliability, plugin conflicts, security, hosting, updates, observability, and support. - **Teams migrating from proprietary platforms:** Gain control over code, hosting, data, extensions, integrations, content, and long-term commerce operation. ### Implementation risks - **Plugin combinations create hidden coupling:** Checkout, orders, subscriptions, product data, themes, emails, and integrations fail after independent updates. - **WordPress performance collapses under commerce load:** Queries, object cache, page cache, sessions, cron, search, images, third parties, and hosting are not designed together. - **Customisation bypasses supported extension points:** Core edits and theme-level business logic make updates unsafe and ownership difficult. ### Platform capabilities - WooCommerce architecture, hosting, theme, plugin, security, performance, and lifecycle assessment - Custom WordPress themes, block themes, storefront components, accessibility, and conversion experience - Custom WooCommerce plugins, hooks, actions, filters, REST APIs, webhooks, and scheduled processing - Subscriptions, memberships, bookings, marketplaces, bundles, pricing, B2B, and specialised product models - Payment, tax, shipping, inventory, ERP, CRM, fulfilment, support, finance, and analytics integration - Database, query, cache, CDN, image, search, queue, cron, checkout, and infrastructure optimisation - Migration, staging, testing, updates, monitoring, backups, recovery, security, and managed maintenance ### Implementation system - **WordPress commerce foundation:** Hosting, runtime, database, cache, CDN, files, cron, queues, security, backups, staging, and deployment. - **Theme and extension system:** Storefront, blocks, templates, plugins, custom code, hooks, compatibility, ownership, and update lifecycle. - **Commerce domain:** Products, variations, prices, inventory, carts, checkout, orders, payments, subscriptions, refunds, and customers. - **Operational integrations:** Shipping, tax, ERP, CRM, WMS, support, accounting, marketing, analytics, email, and reconciliation. ### Use cases - **Custom WooCommerce store:** Deliver a differentiated product, content, checkout, payment, account, and operational experience. - **WooCommerce subscriptions:** Implement recurring products, renewals, payment gateways, plan changes, failed payments, entitlements, and reporting. - **WooCommerce marketplace or B2B:** Support vendors, commissions, approvals, company buyers, pricing, tax, permissions, orders, and fulfilment. - **Performance and stability rescue:** Diagnose slow pages, checkout failures, plugin conflicts, database load, cron, cache, hosting, and update risk. ### Architecture - **Custom logic belongs in versioned plugins:** Keep business rules, integrations, data changes, and scheduled processes outside core files and presentation themes. - **Dynamic commerce bypasses page-cache assumptions:** Design sessions, carts, accounts, checkout, inventory, search, personalisation, and APIs around appropriate caching layers. - **Updates are treated as releases:** Test WordPress, WooCommerce, themes, extensions, PHP, database, and integration changes in staging before controlled deployment. ### Quality and governance - **Transaction integrity:** Pricing, inventory, tax, payment, order, fulfilment, refund, promotion, and customer state remain consistent across systems. - **Performance and conversion:** Storefront rendering, search, product data, checkout, third parties, analytics, and mobile behaviour are measured and optimised. - **Upgrade-safe extensibility:** Themes, extensions, APIs, webhooks, custom services, and platform capabilities are used with clear ownership and lifecycle planning. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - WooCommerce code, hosting, theme, plugin, performance, and security assessment - Storefront, extension, commerce, integration, infrastructure, and migration architecture - Production theme, custom plugins, APIs, subscriptions, marketplace, or B2B features - Payment, shipping, tax, inventory, ERP, CRM, fulfilment, and analytics integrations - Staging, tests, deployment, monitoring, backups, security, and performance controls - Merchant, developer, administrator, support, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad build custom WooCommerce plugins?** Yes. We develop versioned plugins using supported hooks, APIs, database patterns, background processing, settings, permissions, tests, and deployment controls. - **Can a slow WooCommerce site be improved?** Yes. We profile frontend, PHP, database, queries, cache, cron, sessions, plugins, search, images, hosting, and third parties before targeted remediation. - **Can Rokad migrate Shopify or another platform to WooCommerce?** Yes. We map catalogue, variants, customers, orders, content, redirects, subscriptions, reviews, integrations, and reporting before migration. - **Can Rokad maintain WooCommerce continuously?** Yes. Managed maintenance can cover updates, security, backups, performance, incidents, plugins, integrations, monitoring, releases, and feature delivery. --- ## [Platform service] BigCommerce development services Canonical URL: https://rokad.co/en/services/software-development/ecommerce/bigcommerce Platform: BigCommerce > Rokad develops and integrates BigCommerce storefronts, headless experiences, B2B workflows, multi-storefront operations, custom applications, and platform migrations. BigCommerce supports managed commerce together with API-led and composable implementation patterns. Rokad designs storefront, catalogue, channel, customer, checkout, B2B, integration, and data boundaries, then develops the required frontend, applications, middleware, migration, and production controls. ### Designed for - **Mid-market and enterprise merchants:** Launch scalable B2C or B2B commerce with complex catalogue, pricing, channels, integrations, and operating requirements. - **Brands adopting headless or composable storefronts:** Separate frontend experience from commerce services while maintaining checkout, accounts, merchandising, and operations. - **Organisations managing several storefronts:** Coordinate brands, regions, channels, catalogues, content, pricing, customers, and shared integrations. ### Implementation risks - **Channel and catalogue rules become inconsistent:** Products, categories, prices, inventory, promotions, customer groups, and content diverge across storefronts and external systems. - **Headless delivery loses merchant usability:** Preview, content, merchandising, checkout, accounts, analytics, and release workflows are not designed with the frontend architecture. - **Enterprise integrations create order-state drift:** ERP, inventory, fulfilment, payment, tax, shipping, customer, and support systems disagree on transaction status. ### Platform capabilities - BigCommerce storefront, Stencil, headless, composable, and multi-storefront architecture - Catalogue, categories, channels, price lists, customer groups, promotions, checkout, and accounts - Custom applications, widgets, scripts, APIs, webhooks, middleware, and merchant tooling - B2B company, buyer, pricing, quote, order, approval, and account workflows - ERP, PIM, WMS, OMS, CRM, fulfilment, tax, payment, shipping, support, and analytics integration - Headless frontend, content, search, preview, caching, deployment, and performance engineering - Migration, data validation, redirects, testing, monitoring, support, and managed operation ### Implementation system - **Commerce configuration:** Catalogues, channels, pricing, promotions, customer groups, accounts, checkout, tax, shipping, and payments. - **Storefront and experience:** Stencil or headless frontend, content, search, merchandising, preview, accessibility, performance, and analytics. - **Application and integration layer:** APIs, webhooks, custom apps, middleware, enterprise systems, transformations, reconciliation, and operator tools. - **Multi-store operation:** Brands, regions, channels, catalogues, content, domains, integrations, permissions, releases, and shared governance. ### Use cases - **Enterprise B2C storefront:** Deliver a high-performance customer experience with complex product, promotion, payment, fulfilment, and integration requirements. - **BigCommerce B2B platform:** Support organisations, buyers, price lists, quotes, approvals, credit, orders, accounts, and ERP workflows. - **Multi-storefront commerce:** Operate several brands, countries, channels, catalogues, and experiences on a governed shared foundation. - **Headless commerce implementation:** Build a custom frontend around BigCommerce APIs, checkout, customer accounts, content, search, and observability. ### Architecture - **Channel-aware data model:** Define which catalogue, price, inventory, content, customer, and promotion values vary by storefront or remain shared. - **Headless frontend preserves commerce contracts:** Design customer, cart, checkout, account, price, promotion, and inventory behaviour around supported APIs and platform state. - **Order lifecycle is reconciled:** Track identifiers and status across BigCommerce, payments, tax, ERP, OMS, fulfilment, returns, and customer service. ### Quality and governance - **Transaction integrity:** Pricing, inventory, tax, payment, order, fulfilment, refund, promotion, and customer state remain consistent across systems. - **Performance and conversion:** Storefront rendering, search, product data, checkout, third parties, analytics, and mobile behaviour are measured and optimised. - **Upgrade-safe extensibility:** Themes, extensions, APIs, webhooks, custom services, and platform capabilities are used with clear ownership and lifecycle planning. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - BigCommerce storefront, catalogue, channel, B2B, integration, and migration assessment - Commerce, multi-storefront, headless, application, and enterprise integration architecture - Production Stencil or headless storefront and custom platform applications - B2B, catalogue, price, customer, checkout, order, and operational integrations - Migration, redirects, test, deployment, performance, monitoring, and reconciliation controls - Merchant, developer, operator, support, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad build a headless BigCommerce storefront?** Yes. We can develop frontend, content, search, customer, cart, checkout, caching, deployment, analytics, and operational integrations around supported APIs. - **Can BigCommerce support several stores or brands?** Yes. We design channels, catalogues, pricing, content, domains, permissions, integrations, analytics, and shared governance around the required operating model. - **Can Rokad implement BigCommerce B2B?** Yes. Scope can include company accounts, buyers, price lists, quotes, approvals, payment terms, orders, ERP integration, and account administration. - **Can Rokad migrate from Shopify, Magento, or another platform?** Yes. We plan products, variants, categories, customers, orders, content, redirects, reviews, subscriptions, integrations, and operational transition. --- ## [Platform service] Adobe Commerce development services Canonical URL: https://rokad.co/en/services/software-development/ecommerce/adobe-commerce Platform: Adobe Commerce > Rokad develops, modernises, integrates, and maintains Adobe Commerce and Magento Open Source platforms for complex B2B and B2C operations. Adobe Commerce supports deep catalogue, customer, promotion, order, B2B, extension, and integration requirements, but the implementation must control custom modules, upgrades, indexing, caching, queues, search, infrastructure, and enterprise data. Rokad engineers the application and its operating platform together. ### Designed for - **Enterprises operating complex Adobe Commerce estates:** Improve modules, integrations, performance, security, upgrades, cloud operation, and release reliability. - **B2B merchants with organisational buying workflows:** Implement companies, buyers, roles, catalogues, pricing, quotes, approvals, credit, orders, and ERP integration. - **Magento teams preparing modernisation or migration:** Assess custom code, extensions, themes, data, infrastructure, support status, and the safest target path. ### Implementation risks - **Custom modules make upgrades unsafe:** Core overrides, outdated extensions, tight coupling, unsupported APIs, and untested changes create prolonged release risk. - **Indexing and background work affect storefront reliability:** Queues, cron, consumers, cache, search, imports, pricing, inventory, and integrations compete for resources and visibility. - **B2B workflows cross several enterprise systems:** Company, catalogue, price, quote, credit, order, fulfilment, invoice, and customer data require clear ownership and reconciliation. ### Platform capabilities - Adobe Commerce and Magento architecture, code, module, theme, extension, infrastructure, and risk assessment - Custom modules, service contracts, plugins, events, APIs, GraphQL, webhooks, and out-of-process applications - B2B companies, buyers, roles, catalogues, price, quote, approval, credit, and order workflows - Storefront, theme, headless, content, search, merchandising, accessibility, and performance - ERP, PIM, OMS, WMS, CRM, tax, payment, shipping, fulfilment, support, and analytics integration - Cloud, cache, search, database, queues, cron, indexing, deployment, observability, backup, and security - Version upgrades, Magento migration, data migration, testing, monitoring, maintenance, and managed operation ### Implementation system - **Commerce application:** Modules, services, catalogue, customer, cart, checkout, order, B2B, content, search, and administration. - **Extension architecture:** Supported plugins, events, APIs, service contracts, App Builder or external applications, dependencies, and upgrade boundaries. - **Enterprise integration:** ERP, PIM, inventory, price, customer, orders, fulfilment, tax, payment, support, and reconciliation. - **Commerce operations:** Cloud, cache, search, queues, indexing, cron, database, deployment, security, telemetry, upgrades, and support. ### Use cases - **Adobe Commerce B2B implementation:** Deliver company accounts, buyer roles, shared catalogues, negotiated quotes, approvals, credit, and enterprise integrations. - **Adobe Commerce modernisation:** Reduce unsupported customisation, update extensions, improve architecture, performance, security, testing, and deployment. - **Magento upgrade or migration:** Assess code, data, themes, modules, integrations, search, infrastructure, SEO, and operating continuity before transition. - **Performance and reliability programme:** Improve cache, search, indexing, database, queues, cron, imports, frontend, infrastructure, observability, and capacity. ### Architecture - **Extension boundaries protect upgrades:** Use supported service contracts, plugins, events, APIs, and out-of-process patterns while minimising core overrides. - **Asynchronous work is operated explicitly:** Monitor queues, consumers, cron, indexers, imports, webhooks, retries, dead work, and business reconciliation. - **Commerce and enterprise states are reconciled:** Maintain correlation and authority across catalogue, inventory, price, customer, quote, order, invoice, and fulfilment records. ### Quality and governance - **Transaction integrity:** Pricing, inventory, tax, payment, order, fulfilment, refund, promotion, and customer state remain consistent across systems. - **Performance and conversion:** Storefront rendering, search, product data, checkout, third parties, analytics, and mobile behaviour are measured and optimised. - **Upgrade-safe extensibility:** Themes, extensions, APIs, webhooks, custom services, and platform capabilities are used with clear ownership and lifecycle planning. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Adobe Commerce code, module, extension, infrastructure, performance, and risk assessment - Commerce, B2B, extension, integration, storefront, and operating architecture - Production modules, applications, APIs, themes, headless frontend, or B2B capabilities - ERP, PIM, OMS, WMS, payment, tax, shipping, fulfilment, and analytics integrations - Upgrade, migration, test, deployment, observability, security, and recovery controls - Developer, administrator, merchant, operator, support, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad work with Magento Open Source as well as Adobe Commerce?** Yes. We can assess, develop, integrate, upgrade, migrate, and maintain both, while accounting for edition-specific capabilities and support. - **Can custom modules be made safer to upgrade?** Yes. We review overrides, plugins, events, dependencies, APIs, tests, data patches, frontend coupling, and externalisation opportunities before refactoring. - **Can Rokad implement Adobe Commerce B2B?** Yes. We can deliver company accounts, buyer roles, shared catalogues, price, quote, approval, credit, order, and ERP workflows. - **Can Rokad provide ongoing Adobe Commerce support?** Yes. Managed support can cover incidents, security, patches, upgrades, modules, integrations, performance, queues, deployment, monitoring, and feature delivery. --- ## [Platform service] commercetools development services Canonical URL: https://rokad.co/en/services/software-development/ecommerce/commercetools Platform: commercetools > Rokad designs and builds composable commerce systems on commercetools across domain modelling, APIs, storefronts, integrations, migration, and operations. commercetools provides API-first commerce capabilities that can be composed with independently selected content, search, payment, identity, frontend, data, and operational systems. Rokad defines the domain boundaries, extensions, event flows, integration architecture, migration, storefront, and platform operations required to make that flexibility coherent. ### Designed for - **Enterprises building differentiated composable commerce:** Create custom customer and operator experiences around specialised commerce, content, search, data, and fulfilment services. - **Multi-brand and multi-market organisations:** Model products, channels, stores, prices, inventory, customers, carts, and orders across complex operating structures. - **Teams decomposing a monolithic commerce platform:** Migrate domains gradually using APIs, events, adapters, coexistence, data ownership, and controlled cutover. ### Implementation risks - **Composable freedom creates architecture sprawl:** Teams select many services without clear domain ownership, interfaces, observability, support, or total operating cost. - **Commerce models do not match the business domain:** Product types, variants, attributes, channels, stores, prices, inventory, customers, and orders are configured without durable modelling rules. - **Synchronous integrations create fragile checkout paths:** Pricing, tax, promotions, inventory, payment, identity, and downstream systems add latency and failure to customer transactions. ### Platform capabilities - Composable commerce strategy, capability map, domain boundaries, and vendor architecture - Product types, attributes, variants, categories, projections, stores, channels, prices, and inventory modelling - Customers, carts, discounts, shipping, tax, payments, orders, subscriptions, and business-unit workflows - APIs, extensions, subscriptions, events, custom applications, middleware, and integration services - Custom web and mobile storefronts, content, search, identity, checkout, account, and operator experiences - PIM, ERP, OMS, WMS, payment, tax, promotion, fulfilment, CRM, support, and analytics integration - Migration, coexistence, testing, observability, performance, support, and managed operation ### Implementation system - **Commerce domain model:** Products, variants, attributes, categories, prices, stores, channels, inventory, customers, carts, and orders. - **Composition layer:** Backend-for-frontend, API gateway, orchestration, extensions, subscriptions, events, caching, and service contracts. - **Experience system:** Storefronts, apps, content, search, identity, cart, checkout, accounts, operator tools, and preview. - **Enterprise operations:** PIM, ERP, OMS, WMS, payment, tax, fulfilment, analytics, reconciliation, observability, and support. ### Use cases - **Composable enterprise commerce:** Combine commercetools with selected content, search, frontend, identity, payment, tax, data, and operational services. - **Multi-brand and multi-region platform:** Support shared and local product, price, inventory, content, channel, store, customer, and integration rules. - **Commerce monolith decomposition:** Extract product, cart, order, customer, or channel capabilities through adapters, events, coexistence, and migration waves. - **Custom B2B commerce:** Model business units, buyers, permissions, catalogues, price, quote, approval, order, and enterprise integration requirements. ### Architecture - **Composition has an accountable owner:** Define who owns service selection, contracts, integration, frontend, observability, support, and cross-platform incidents. - **Events decouple non-critical operations:** Use subscriptions and asynchronous processing for downstream updates while preserving transaction identifiers and reconciliation. - **Domain model precedes data migration:** Map existing products, variants, prices, inventory, customers, carts, and orders into deliberate target structures before transfer. ### Quality and governance - **Transaction integrity:** Pricing, inventory, tax, payment, order, fulfilment, refund, promotion, and customer state remain consistent across systems. - **Performance and conversion:** Storefront rendering, search, product data, checkout, third parties, analytics, and mobile behaviour are measured and optimised. - **Upgrade-safe extensibility:** Themes, extensions, APIs, webhooks, custom services, and platform capabilities are used with clear ownership and lifecycle planning. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Composable capability, platform, data, integration, and operational assessment - Commerce domain, composition, storefront, event, and enterprise integration architecture - Production commercetools configuration, extensions, subscriptions, APIs, and middleware - Custom storefront, account, checkout, operator, and multi-channel experiences - Migration, coexistence, reconciliation, test, observability, and release controls - Developer, operator, architecture, support, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **What makes commercetools different from a traditional commerce platform?** It exposes commerce capabilities through APIs, allowing organisations to compose their own frontend, content, search, identity, payment, and operational architecture. - **Can Rokad build the storefront as well?** Yes. We can deliver web and mobile storefronts, backend-for-frontend services, content, search, accounts, cart, checkout, and operator experiences. - **Can commercetools be introduced gradually?** Yes. We can design domain-by-domain migration, adapters, event flows, coexistence, routing, data synchronisation, and controlled cutover. - **Can Rokad operate the composed platform?** Yes. Managed services can cover integrations, storefronts, APIs, events, observability, incidents, vendors, releases, cost, and continuous improvement. --- ## [Platform service] Salesforce Commerce Cloud services Canonical URL: https://rokad.co/en/services/software-development/ecommerce/salesforce-commerce-cloud Platform: Salesforce Commerce Cloud > Rokad develops and integrates Salesforce Commerce Cloud for B2C and B2B commerce, composable storefronts, customer workflows, enterprise systems, and managed operation. Salesforce Commerce Cloud can connect digital commerce with wider customer, service, marketing, and data capabilities. Rokad designs storefront, catalogue, customer, promotion, checkout, B2B, API, cartridge, composable, and integration architecture while preserving release, performance, and operational control. ### Designed for - **Enterprise brands operating Salesforce ecosystems:** Connect commerce with CRM, service, marketing, identity, data, loyalty, and customer operations. - **B2C teams modernising storefront experience:** Develop or migrate to Composable Storefront and PWA Kit while preserving merchandising, checkout, accounts, and integrations. - **B2B organisations digitising complex sales:** Support accounts, buyers, catalogues, pricing, orders, approvals, service, and enterprise system coordination. ### Implementation risks - **Commerce and CRM customer records diverge:** Identity, consent, account, preference, order, service, marketing, and loyalty data lack explicit authority and synchronisation. - **Legacy cartridges restrict storefront change:** Custom code, integrations, templates, dependencies, and release practices make upgrades and composable migration difficult. - **Composable storefront adds operational boundaries:** PWA Kit, Managed Runtime, APIs, content, search, checkout, observability, and release ownership require coordinated design. ### Platform capabilities - Salesforce B2C and B2B commerce discovery, architecture, implementation, and modernisation - Composable Storefront, PWA Kit, Managed Runtime, Storefront APIs, accounts, cart, checkout, and deployment - SFRA, cartridges, hooks, controllers, jobs, OCAPI, SCAPI, custom APIs, and integrations - Catalogue, promotions, search, merchandising, content, customer, order, payment, tax, and fulfilment workflows - Salesforce CRM, Service, Marketing, Data Cloud, identity, loyalty, and customer integration - ERP, PIM, OMS, WMS, payment, tax, shipping, fulfilment, support, and analytics integration - Migration, performance, testing, release, observability, security, support, and managed operation ### Implementation system - **Commerce core:** Catalogue, search, promotions, customer, cart, checkout, order, payment, tax, fulfilment, B2B, and administration. - **Storefront architecture:** SFRA or Composable Storefront, PWA Kit, APIs, content, search, accounts, preview, performance, and deployment. - **Salesforce customer layer:** CRM, service, marketing, identity, loyalty, consent, data, profiles, journeys, and customer-operation boundaries. - **Enterprise integration:** ERP, PIM, OMS, WMS, fulfilment, tax, payment, events, batch, reconciliation, monitoring, and support. ### Use cases - **Composable Storefront implementation:** Develop PWA Kit customer experiences with commerce APIs, content, search, accounts, checkout, analytics, and operations. - **Salesforce-connected commerce:** Coordinate customer, service, marketing, loyalty, identity, data, and commerce workflows across the Salesforce estate. - **Commerce Cloud modernisation:** Refactor cartridges, APIs, integrations, deployment, performance, observability, and frontend architecture. - **B2B commerce programme:** Deliver account, buyer, product, price, order, approval, service, and enterprise integration requirements. ### Architecture - **Storefront pattern follows change requirements:** Select SFRA, composable, or hybrid delivery from experience, team, release, integration, performance, and migration needs. - **Customer identity has one governed model:** Define account, guest, consent, profile, loyalty, service, marketing, and commerce identifiers across Salesforce products. - **Cartridges and APIs have lifecycle controls:** Version custom code, dependencies, hooks, jobs, interfaces, tests, deployment, compatibility, and ownership. ### Quality and governance - **Transaction integrity:** Pricing, inventory, tax, payment, order, fulfilment, refund, promotion, and customer state remain consistent across systems. - **Performance and conversion:** Storefront rendering, search, product data, checkout, third parties, analytics, and mobile behaviour are measured and optimised. - **Upgrade-safe extensibility:** Themes, extensions, APIs, webhooks, custom services, and platform capabilities are used with clear ownership and lifecycle planning. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Commerce Cloud storefront, cartridge, API, customer, integration, and risk assessment - B2C or B2B commerce, composable, Salesforce, and enterprise integration architecture - Production SFRA or PWA Kit storefront, cartridges, APIs, jobs, and custom services - CRM, service, marketing, identity, data, ERP, PIM, OMS, and fulfilment integrations - Migration, performance, security, testing, deployment, observability, and support controls - Developer, merchant, administrator, operator, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad develop Composable Storefront and PWA Kit?** Yes. We can deliver frontend, APIs, content, search, accounts, cart, checkout, deployment, monitoring, and enterprise integration. - **Can Rokad work with existing SFRA cartridges?** Yes. We assess custom cartridges, third-party dependencies, hooks, controllers, jobs, APIs, templates, tests, performance, and upgrade impact. - **Can Commerce Cloud integrate with other Salesforce products?** Yes. We design identity, customer, consent, service, marketing, loyalty, profile, event, and data flows with explicit ownership and reconciliation. - **Can Rokad maintain Commerce Cloud after launch?** Yes. Managed support can cover storefronts, cartridges, APIs, integrations, releases, incidents, performance, monitoring, and roadmap delivery. --- ## [Service specialisation] Enterprise software development Canonical URL: https://rokad.co/en/services/software-development/enterprise-software > Rokad builds secure enterprise applications around complex workflows, organisational controls, integration requirements, and long-term operational ownership. Enterprise software must reflect real organisational structures, exceptions, permissions, data governance, auditability, integration, and change. Rokad develops platforms for operations, customers, partners, workforces, assets, approvals, reporting, and cross-system coordination. ### Designed for - **Organisations replacing fragmented operations:** Consolidate spreadsheets, email, legacy tools, and manual coordination into a governed system of work. - **Enterprises building differentiated internal capability:** Create software around processes that are too strategic, complex, or organisation-specific for standard products. - **Product teams serving enterprise customers:** Add identity, permissions, audit, integration, deployment, and administration capabilities required for enterprise adoption. ### Challenges - **Business rules live in people and spreadsheets:** Critical knowledge, approvals, exceptions, and controls are difficult to enforce, measure, or transfer. - **Standard software forces operational compromise:** Teams adapt strategic workflows around product limitations, creating workarounds and disconnected data. - **Existing systems cannot change safely:** Tightly coupled architecture, undocumented behaviour, and integration risk make every improvement slow and expensive. ### Capabilities - Domain, workflow, and organisational modelling - Role, policy, permission, approval, and delegation systems - Operational, customer, partner, workforce, and asset applications - Enterprise identity, SSO, directories, audit, and compliance controls - ERP, CRM, finance, data, document, and third-party integration - Migration, phased rollout, reporting, observability, and managed support ### Solution components - **Operational workflows:** Cases, tasks, approvals, exceptions, service levels, collaboration, queues, and business-rule execution. - **Governance and control:** Identity, permissions, delegation, segregation, audit, retention, policy, and administrative oversight. - **Enterprise integration:** Reliable coordination with systems of record, documents, communications, data platforms, and external partners. - **Management intelligence:** Operational reporting, performance, bottlenecks, risk, compliance evidence, and decision-support views. ### Use cases - **Operations management platform:** Coordinate work, ownership, approvals, exceptions, documents, communication, and performance across teams. - **Customer or partner portal:** Provide secure self-service, transactions, cases, documents, status, communication, and account administration. - **Enterprise product enablement:** Add SSO, SCIM, roles, audit, environments, integration, administration, and governance to an existing product. - **Legacy business-system replacement:** Rebuild critical workflows and data on a maintainable architecture with phased migration and continuity controls. ### Architecture and integration - **Domain boundaries:** Separate business capabilities, data ownership, workflows, and integrations to reduce coupling and support controlled change. - **Identity and policy:** Represent organisational structure, roles, delegated authority, conditional access, and auditable decision rights. - **Integration resilience:** Use contracts, queues, idempotency, reconciliation, monitoring, and failure handling for dependable cross-system operation. ### Quality and control - **Secure engineering:** Permissions, data boundaries, secrets, dependencies, threat scenarios, and recovery requirements are addressed throughout delivery. - **Production readiness:** Testing, observability, performance, deployment controls, rollback planning, and operating documentation are included in the definition of done. - **Maintainable ownership:** The client receives structured source code, technical documentation, operating knowledge, and a practical path for future development. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - Process, domain, role, and system discovery - Enterprise architecture, data, integration, and rollout plan - Production application, administration, and source code - Identity, permission, audit, reporting, and integration controls - Migration, test, deployment, and change-support package - Technical, user, administrator, and operating documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad integrate with existing enterprise systems?** Yes. We can integrate with identity, ERP, CRM, finance, document, data, communication, and industry systems through APIs, events, files, queues, or controlled adapters. - **How are complex permissions handled?** We model roles, attributes, organisational boundaries, delegated authority, segregation requirements, approval context, and audit evidence rather than relying only on simple role lists. - **Can implementation be phased?** Yes. We can sequence capabilities, business units, integrations, and data migration to reduce operational disruption and validate the system progressively. - **Can Rokad replace a legacy enterprise application?** Yes. We document existing behaviour and dependencies, prioritise critical workflows, design migration and coexistence, and maintain continuity through controlled cutover. --- ## [Platform service] Salesforce development and integration services Canonical URL: https://rokad.co/en/services/software-development/enterprise-software/salesforce Platform: Salesforce > Rokad develops, integrates, modernises, and governs Salesforce platforms across CRM, automation, custom applications, customer portals, data, and enterprise systems. Salesforce can become a customer and operational platform spanning sales, service, partner, marketing, data, workflows, and custom applications. Rokad defines the data model, process, automation, code, integration, identity, environment, release, security, and ownership architecture required for sustainable enterprise use. ### Designed for - **Companies implementing or redesigning Salesforce:** Align customer processes, records, roles, automation, reporting, integrations, and adoption with the operating model. - **Enterprises extending Salesforce with custom applications:** Build Apex, Lightning, Flow, portals, APIs, events, external services, and domain-specific capabilities. - **Organisations reducing Salesforce technical debt:** Improve automation sprawl, custom code, data quality, security, integrations, environments, releases, and governance. ### Implementation risks - **Automation is spread across too many mechanisms:** Flows, Apex, validation, approvals, triggers, integrations, and managed packages overlap and create unexpected behaviour. - **CRM data lacks clear ownership:** Accounts, contacts, leads, opportunities, cases, products, activities, consent, and external records conflict across systems. - **Production changes bypass release discipline:** Configuration, code, metadata, permissions, data, integrations, and packages are changed without environments, tests, review, and rollback. ### Platform capabilities - Salesforce discovery, process, data, security, architecture, licence, and implementation planning - Sales Cloud, Service Cloud, Experience Cloud, Data Cloud, platform, and custom application development - Flow, approvals, validation, Apex, triggers, asynchronous jobs, Lightning Web Components, and user experience - Custom and standard objects, relationships, record types, sharing, roles, permissions, and data quality - REST, SOAP, Bulk, Platform Events, Change Data Capture, external services, middleware, and enterprise integration - Communities and portals, identity, SSO, customer and partner workflows, forms, documents, and service experiences - Data migration, DevOps, testing, environments, monitoring, security, support, governance, and managed evolution ### Implementation system - **CRM and domain model:** Objects, relationships, ownership, lifecycle, roles, permissions, customer identity, activities, products, and service records. - **Automation and application layer:** Flow, Apex, validation, approvals, Lightning, portals, jobs, notifications, documents, and user interfaces. - **Enterprise integration:** ERP, marketing, support, finance, data, identity, products, events, APIs, middleware, and reconciliation. - **Platform operations:** Sandboxes, source control, deployments, tests, permissions, monitoring, data, packages, releases, support, and governance. ### Use cases - **Salesforce CRM implementation:** Configure customer, lead, opportunity, account, activity, forecast, approval, reporting, and sales-operation workflows. - **Customer service platform:** Deliver case management, routing, knowledge, channels, entitlements, automation, customer context, and escalation. - **Salesforce custom application:** Build domain-specific records, workflows, portals, Lightning interfaces, APIs, documents, and enterprise integrations. - **Salesforce modernisation:** Reduce obsolete automation and code, improve data, permissions, integration, releases, testing, performance, and governance. ### Architecture - **Choose configuration, Flow, and Apex deliberately:** Use the simplest supported mechanism that meets transaction, scale, test, reuse, performance, and lifecycle requirements. - **Customer and master data have explicit authority:** Define which system owns each entity and field, how updates flow, how duplicates resolve, and how history is retained. - **Metadata changes follow software delivery:** Version configuration and code, validate dependencies, automate tests, promote through environments, and preserve release evidence. ### Quality and governance - **Data and process integrity:** Records, ownership, states, approvals, deduplication, validation, reconciliation, and system-of-record boundaries are explicit. - **Governed customisation:** Configuration, extensions, code, integrations, environments, permissions, and release controls preserve platform maintainability. - **Adoption and operation:** User roles, training, support, reporting, administration, change management, and platform ownership are part of delivery. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Salesforce process, data, licence, security, automation, code, integration, and risk assessment - CRM, application, object, permission, automation, integration, and operating architecture - Production configuration, Flow, Apex, Lightning, portals, APIs, and custom applications - ERP, marketing, service, finance, data, identity, event, and middleware integrations - Migration, data quality, testing, DevOps, security, monitoring, and release controls - User, administrator, developer, operator, governance, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad build custom Salesforce applications?** Yes. We can develop objects, Flow, Apex, Lightning Web Components, portals, APIs, jobs, documents, permissions, and integrations. - **Can Rokad integrate Salesforce with ERP and other systems?** Yes. We use supported APIs, events, middleware, files, queues, or controlled adapters with data ownership, validation, reconciliation, monitoring, and error handling. - **Can existing Salesforce automation be audited?** Yes. We review Flow, Apex, validation, approvals, triggers, packages, integrations, limits, failures, ownership, duplication, and maintainability. - **Can Rokad manage Salesforce after launch?** Yes. Managed services can cover administration, users, permissions, data, automation, code, integrations, releases, incidents, reporting, and roadmap delivery. --- ## [Platform service] HubSpot development and integration services Canonical URL: https://rokad.co/en/services/software-development/enterprise-software/hubspot Platform: HubSpot > Rokad implements, extends, integrates, migrates, and governs HubSpot across CRM, marketing, sales, service, content, automation, custom objects, and applications. HubSpot can connect customer acquisition, sales, service, content, automation, and reporting around one CRM. Rokad defines lifecycle stages, objects, properties, associations, ownership, workflows, integrations, data quality, applications, permissions, reporting, and operating practices. ### Designed for - **Growth companies implementing a shared customer platform:** Align marketing, sales, onboarding, service, success, operations, content, and reporting around common records and processes. - **Teams extending HubSpot beyond standard configuration:** Build custom objects, applications, workflow actions, UI extensions, integrations, data synchronisation, and operational tooling. - **Organisations cleaning up an overgrown HubSpot portal:** Rationalise properties, lists, workflows, pipelines, forms, integrations, permissions, reports, and data quality. ### Implementation risks - **Lifecycle and pipeline definitions differ by team:** Marketing, sales, service, success, and finance interpret status, ownership, qualification, and conversion differently. - **Properties and workflows accumulate without governance:** Duplicate fields, lists, automations, branches, delays, enrolment rules, and integrations create conflicting updates. - **CRM reporting is built on inconsistent records:** Duplicates, missing associations, weak validation, unclear source, overwritten history, and incomplete activity reduce trust. ### Platform capabilities - HubSpot CRM, lifecycle, pipeline, object, association, property, permission, and governance design - Marketing, Sales, Service, Content, and Operations Hub implementation and cross-hub workflows - Custom objects, schemas, properties, associations, pipelines, records, and domain-specific CRM models - Workflows, lists, lead routing, scoring, approvals, sequences, tasks, notifications, and operational automation - Private and public apps, OAuth, APIs, webhooks, custom workflow actions, UI extensions, and middleware - ERP, finance, product, support, ecommerce, data warehouse, enrichment, communication, and analytics integration - Migration, deduplication, validation, attribution, reporting, training, support, and managed administration ### Implementation system - **Customer data model:** Contacts, companies, deals, tickets, custom objects, associations, properties, lifecycle, ownership, and history. - **Revenue and service operations:** Pipelines, stages, routing, scoring, workflows, tasks, approvals, handoffs, service, onboarding, and success. - **Application and integration layer:** Apps, OAuth, APIs, webhooks, workflow actions, UI extensions, middleware, external systems, and reconciliation. - **Portal governance:** Teams, permissions, naming, properties, workflows, lists, assets, reports, releases, data quality, and support. ### Use cases - **HubSpot CRM implementation:** Define lifecycle, pipelines, objects, ownership, activities, workflows, reporting, permissions, and adoption. - **HubSpot custom integration:** Connect product, ERP, billing, support, ecommerce, data, enrichment, communications, and operational systems. - **Revenue operations automation:** Coordinate lead capture, enrichment, scoring, routing, sales, proposals, onboarding, billing, renewal, and reporting. - **HubSpot portal cleanup:** Audit and rationalise records, properties, associations, workflows, lists, pipelines, permissions, integrations, and reports. ### Architecture - **Objects reflect durable business entities:** Use standard or custom objects and associations for real domain relationships instead of encoding structure into fields and lists. - **Workflow enrolment is controlled:** Define triggers, re-enrolment, exclusions, delays, branch order, ownership, idempotency, exit, and monitoring for each automation. - **External synchronisation has field-level authority:** Specify which system creates and owns every record and property, conflict handling, deletion, history, and reconciliation. ### Quality and governance - **Data and process integrity:** Records, ownership, states, approvals, deduplication, validation, reconciliation, and system-of-record boundaries are explicit. - **Governed customisation:** Configuration, extensions, code, integrations, environments, permissions, and release controls preserve platform maintainability. - **Adoption and operation:** User roles, training, support, reporting, administration, change management, and platform ownership are part of delivery. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - HubSpot portal, lifecycle, object, workflow, integration, data, permission, and reporting assessment - CRM, custom-object, automation, app, integration, data-quality, and governance architecture - Production portal configuration, workflows, custom objects, apps, APIs, and UI extensions - Product, ERP, finance, support, ecommerce, enrichment, data, and communication integrations - Migration, deduplication, validation, testing, attribution, reporting, and monitoring controls - User, administrator, developer, operations, governance, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad build custom HubSpot objects and applications?** Yes. We can design custom objects, properties, associations, pipelines, apps, OAuth, APIs, webhooks, workflow actions, and UI extensions. - **Can HubSpot integrate with our product and billing systems?** Yes. We define customer and subscription identifiers, field ownership, events, API flows, reconciliation, monitoring, and error handling. - **Can Rokad clean up an existing HubSpot account?** Yes. We audit records, duplicates, properties, workflows, lists, pipelines, integrations, permissions, assets, reports, and usage before controlled rationalisation. - **Can Rokad provide ongoing HubSpot administration?** Yes. Managed support can cover users, permissions, data, workflows, properties, integrations, campaigns, reports, incidents, and operational improvement. --- ## [Platform service] Microsoft Dynamics 365 services Canonical URL: https://rokad.co/en/services/software-development/enterprise-software/microsoft-dynamics-365 Platform: Microsoft Dynamics 365 > Rokad implements, extends, integrates, and operates Microsoft Dynamics 365 and Dataverse across customer, service, field, operations, Power Platform, and enterprise systems. Dynamics 365 applications connect customer and operational processes with Dataverse, Microsoft 365, Power Platform, Azure, and enterprise systems. Rokad designs the data, process, extension, integration, identity, environment, solution, release, security, and adoption architecture around the selected applications. ### Designed for - **Microsoft organisations implementing CRM and service:** Build sales, customer service, field service, case, account, activity, knowledge, and customer workflows. - **Enterprises connecting operations and Power Platform:** Integrate finance and operations, Dataverse, Power Apps, Power Automate, Microsoft 365, Azure, and external systems. - **Teams modernising legacy Dynamics implementations:** Reduce unsupported customisation, improve solutions, data, permissions, integrations, automation, release, and governance. ### Implementation risks - **Dynamics applications and Dataverse are designed separately:** Customer, service, product, finance, operations, identity, and integration records duplicate or conflict. - **Customisation bypasses the solution lifecycle:** Tables, forms, plugins, flows, apps, environment variables, connections, and security changes cannot be promoted safely. - **Microsoft ecosystem integration lacks one owner:** Teams, Outlook, SharePoint, Azure, Power Platform, Dynamics apps, and external systems evolve without shared governance. ### Platform capabilities - Dynamics 365 application, process, data, licence, security, integration, and implementation assessment - Sales, Customer Service, Field Service, and selected finance and operations workflows - Dataverse tables, relationships, forms, views, model-driven apps, business rules, plugins, and custom APIs - Power Apps, Power Automate, approvals, connectors, custom connectors, portals, and Power Platform integration - Microsoft 365, Teams, Outlook, SharePoint, Azure, identity, reporting, and Copilot-related integration - ERP, finance, product, inventory, service, data, middleware, file, event, and external-system integration - Migration, solutions, environments, DevOps, testing, security, monitoring, training, and managed support ### Implementation system - **Dynamics application model:** Accounts, contacts, leads, opportunities, cases, work orders, products, activities, organisations, and processes. - **Dataverse and Power Platform:** Tables, security, apps, forms, views, plugins, flows, portals, connectors, solutions, and environment configuration. - **Microsoft integration:** Identity, Microsoft 365, Teams, Outlook, SharePoint, Azure, analytics, data, files, and application services. - **Enterprise operations:** Finance, ERP, inventory, product, service, middleware, data ownership, reconciliation, releases, support, and governance. ### Use cases - **Dynamics 365 Sales implementation:** Configure customer, lead, opportunity, activity, product, quote, forecast, approval, reporting, and sales operations. - **Customer and field service platform:** Coordinate cases, knowledge, routing, entitlements, work orders, assets, scheduling, technicians, parts, and communication. - **Dataverse business application:** Build custom tables, model-driven apps, plugins, flows, portals, APIs, security, reporting, and integrations. - **Dynamics integration and modernisation:** Connect applications and replace unsupported customisation with governed solutions, APIs, flows, plugins, and Azure services. ### Architecture - **Dataverse is a governed enterprise data boundary:** Define table authority, ownership, security, relationships, events, synchronisation, history, and lifecycle across applications. - **Solutions carry all deployable change:** Package tables, apps, flows, plugins, connection references, environment variables, roles, and dependencies for promotion. - **Integration uses the appropriate Microsoft layer:** Select Dataverse, Power Platform, Azure, APIs, events, virtual tables, files, or middleware from latency, volume, ownership, and reliability. ### Quality and governance - **Data and process integrity:** Records, ownership, states, approvals, deduplication, validation, reconciliation, and system-of-record boundaries are explicit. - **Governed customisation:** Configuration, extensions, code, integrations, environments, permissions, and release controls preserve platform maintainability. - **Adoption and operation:** User roles, training, support, reporting, administration, change management, and platform ownership are part of delivery. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Dynamics application, Dataverse, Power Platform, integration, licence, security, and risk assessment - Process, data, solution, application, identity, integration, environment, and operating architecture - Production Dynamics configuration, Dataverse apps, plugins, flows, portals, APIs, and extensions - Microsoft 365, Azure, ERP, finance, product, service, data, and external integrations - Migration, testing, solution deployment, security, monitoring, training, and release controls - User, administrator, developer, operations, governance, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad build custom applications on Dataverse?** Yes. We can develop tables, relationships, security, model-driven apps, plugins, custom APIs, flows, portals, reports, and integrations. - **Can Dynamics 365 integrate with Microsoft 365 and Azure?** Yes. We can integrate identity, Teams, Outlook, SharePoint, Power Platform, Azure services, data platforms, APIs, and monitoring. - **Can existing Dynamics customisation be modernised?** Yes. We assess legacy workflows, code, plugins, forms, integrations, data, permissions, solutions, and support status before staged replacement. - **Can Rokad provide ongoing Dynamics support?** Yes. Managed support can cover users, security, data, apps, flows, plugins, integrations, solutions, releases, incidents, and roadmap changes. --- ## [Platform service] Odoo development and implementation services Canonical URL: https://rokad.co/en/services/software-development/enterprise-software/odoo Platform: Odoo > Rokad implements, customises, integrates, migrates, and maintains Odoo across ERP, CRM, sales, inventory, finance, manufacturing, ecommerce, and business operations. Odoo provides an integrated suite of business applications and an extensible Python-based framework. Rokad maps operating processes, configures standard applications, develops controlled custom modules, integrates external systems, migrates data, and establishes deployment, upgrade, security, training, and support practices. ### Designed for - **SMEs consolidating fragmented business systems:** Bring CRM, sales, purchasing, inventory, finance, manufacturing, projects, HR, service, and ecommerce into one platform. - **Organisations requiring specialised ERP workflows:** Extend Odoo with custom models, views, automation, reports, portals, documents, APIs, and domain-specific modules. - **Companies replacing spreadsheets or legacy ERP:** Migrate master and transaction data while redesigning processes, roles, approvals, reports, and operational ownership. ### Implementation risks - **Customisation recreates standard functionality:** Teams build modules before evaluating supported configuration, applications, community or enterprise capabilities, and process adaptation. - **ERP data migration is treated as file import:** Master data, units, taxes, accounts, stock, open documents, history, identifiers, and reconciliation are not prepared. - **Modules make version upgrades difficult:** Overrides, dependencies, database changes, views, reports, assets, and third-party modules lack compatibility and tests. ### Platform capabilities - Odoo process, application, data, edition, licence, hosting, customisation, and implementation assessment - CRM, sales, purchase, inventory, accounting, manufacturing, projects, field service, HR, ecommerce, and website configuration - Custom Python modules, ORM models, business logic, views, reports, workflows, scheduled jobs, and portals - Roles, record rules, multi-company, multi-currency, tax, approval, audit, and operational controls - Payment, shipping, banking, ecommerce, CRM, marketplace, devices, data, APIs, and enterprise integration - Data migration, master data, opening balances, inventory, documents, reconciliation, validation, and cutover - Hosting, containers, deployment, backups, monitoring, security, upgrades, training, support, and managed operation ### Implementation system - **Business process and applications:** Sales, purchase, inventory, finance, manufacturing, projects, service, HR, ecommerce, roles, approvals, and reporting. - **Odoo extension layer:** Modules, models, fields, views, reports, automation, jobs, controllers, APIs, portal, assets, and dependencies. - **Data and integration:** Master records, transactions, opening state, identifiers, files, APIs, external systems, synchronisation, and reconciliation. - **ERP operations:** Hosting, database, workers, queues, files, email, security, deployment, backup, monitoring, upgrades, and support. ### Use cases - **Odoo ERP implementation:** Configure core applications, processes, roles, approvals, data, reports, integrations, training, and cutover. - **Custom Odoo module:** Develop specialised records, workflows, calculations, portals, documents, reports, devices, and external integrations. - **Odoo ecommerce and operations:** Connect website, products, customers, sales, payment, shipping, inventory, purchasing, accounting, and fulfilment. - **Odoo upgrade and rescue:** Assess modules, data, hosting, performance, security, support, dependencies, and the safest version migration path. ### Architecture - **Configure before customising:** Use supported applications and configuration where they meet requirements, then isolate justified custom behaviour in versioned modules. - **ERP transactions preserve accounting and stock integrity:** Design documents, states, postings, moves, valuation, taxes, units, cancellations, and corrections around Odoo's domain rules. - **Custom modules are upgrade assets:** Maintain manifests, dependencies, tests, migration scripts, documentation, ownership, and version compatibility for each extension. ### Quality and governance - **Data and process integrity:** Records, ownership, states, approvals, deduplication, validation, reconciliation, and system-of-record boundaries are explicit. - **Governed customisation:** Configuration, extensions, code, integrations, environments, permissions, and release controls preserve platform maintainability. - **Adoption and operation:** User roles, training, support, reporting, administration, change management, and platform ownership are part of delivery. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Odoo process, application, edition, module, data, hosting, licence, and risk assessment - ERP process, module, permission, data, integration, migration, and operating architecture - Production Odoo configuration, custom modules, reports, portals, APIs, and workflows - Payment, shipping, banking, ecommerce, devices, data, and enterprise integrations - Migration, reconciliation, testing, deployment, security, backup, monitoring, and cutover controls - User, administrator, developer, finance, operations, support, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad develop custom Odoo modules?** Yes. We can develop models, fields, business logic, views, reports, portals, controllers, APIs, scheduled jobs, permissions, tests, and migration scripts. - **Can Rokad migrate data from another ERP?** Yes. We map master data, accounts, taxes, products, customers, suppliers, stock, opening balances, open documents, identifiers, history, and reconciliation. - **Can existing Odoo customisation be upgraded?** Yes. We assess modules, dependencies, overrides, views, reports, data, APIs, tests, hosting, and edition changes before staged upgrade. - **Can Rokad host and support Odoo?** Yes. Managed services can include cloud or container hosting, deployment, backups, monitoring, security, performance, upgrades, modules, users, incidents, and improvements. --- ## [Platform service] Zoho development and integration services Canonical URL: https://rokad.co/en/services/software-development/enterprise-software/zoho Platform: Zoho > Rokad implements, customises, integrates, migrates, and manages Zoho applications across CRM, finance, service, analytics, automation, and custom business workflows. Zoho provides a broad suite of connected business applications and low-code development capabilities. Rokad designs the customer and operational data model, application boundaries, workflows, custom functions, Creator applications, integrations, migration, reporting, permissions, and platform governance. ### Designed for - **SMEs consolidating customer and business operations:** Connect CRM, finance, service, marketing, analytics, documents, projects, inventory, and internal workflows. - **Teams building custom applications on Zoho:** Use Zoho Creator, functions, APIs, extensions, widgets, forms, reports, and workflows for specialised operations. - **Organisations cleaning up several Zoho products:** Clarify records, integrations, permissions, automations, reporting, subscriptions, ownership, and duplicate capabilities. ### Implementation risks - **Applications are adopted independently:** CRM, Books, Desk, Inventory, Projects, Analytics, Flow, and custom apps use inconsistent customers, products, owners, and statuses. - **Custom functions become undocumented dependencies:** Deluge logic, webhooks, schedules, connections, credentials, APIs, and error handling lack source, tests, ownership, and monitoring. - **Low-code customisation outgrows platform boundaries:** Complex transactions, high volume, specialised interfaces, data processing, or external systems require clearer service architecture. ### Platform capabilities - Zoho application, process, data, licence, integration, automation, security, and governance assessment - Zoho CRM modules, layouts, fields, pipelines, blueprints, approvals, scoring, workflows, and reporting - Zoho Creator applications, forms, pages, reports, permissions, workflows, Deluge functions, and portals - Zoho Books, Desk, Inventory, Analytics, Projects, Campaigns, Flow, WorkDrive, and suite integration - Custom functions, APIs, webhooks, widgets, extensions, connections, schedules, and middleware - ERP, ecommerce, payment, communication, product, support, data, identity, and external-system integration - Migration, deduplication, validation, reporting, training, monitoring, support, and managed administration ### Implementation system - **Zoho business data model:** Customers, contacts, deals, products, invoices, tickets, projects, assets, activities, custom records, and ownership. - **Workflow and application layer:** Blueprints, approvals, workflows, Creator apps, forms, portals, functions, notifications, documents, and reports. - **Suite and external integration:** Zoho applications, APIs, webhooks, Flow, middleware, external systems, data mapping, identifiers, and reconciliation. - **Platform governance:** Organisations, users, roles, licences, connections, functions, apps, data, releases, reports, support, and lifecycle. ### Use cases - **Zoho CRM implementation:** Configure customer, lead, deal, activity, pipeline, blueprint, approval, automation, reporting, permission, and adoption. - **Zoho Creator business application:** Build custom operational records, forms, workflows, portals, dashboards, functions, documents, and integrations. - **Zoho suite integration:** Coordinate CRM, finance, inventory, service, projects, analytics, files, marketing, and custom applications. - **Zoho migration and cleanup:** Rationalise modules, fields, records, duplicates, workflows, functions, connections, permissions, reports, and integrations. ### Architecture - **One authoritative record per domain:** Define whether CRM, Books, Desk, Inventory, Creator, or an external system owns each customer, product, transaction, and status. - **Functions have software lifecycle controls:** Document inputs, outputs, connections, errors, retries, ownership, test cases, deployment, monitoring, and dependencies. - **Use custom services when complexity demands it:** Move high-volume, stateful, security-sensitive, or transaction-heavy logic into maintainable software while Zoho coordinates user workflows. ### Quality and governance - **Data and process integrity:** Records, ownership, states, approvals, deduplication, validation, reconciliation, and system-of-record boundaries are explicit. - **Governed customisation:** Configuration, extensions, code, integrations, environments, permissions, and release controls preserve platform maintainability. - **Adoption and operation:** User roles, training, support, reporting, administration, change management, and platform ownership are part of delivery. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Zoho application, process, data, licence, function, integration, security, and risk assessment - CRM, Creator, suite, workflow, function, integration, data, and governance architecture - Production Zoho configuration, Creator apps, functions, workflows, reports, portals, and extensions - Finance, service, inventory, ecommerce, payment, product, communication, data, and external integrations - Migration, deduplication, validation, testing, monitoring, reporting, and release controls - User, administrator, developer, operations, governance, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad build custom applications with Zoho Creator?** Yes. We can design forms, data models, pages, workflows, portals, reports, permissions, Deluge functions, APIs, and integrations. - **Can different Zoho products share data reliably?** Yes. We define record authority, identifiers, field mappings, events, API flows, validation, conflict handling, reconciliation, and monitoring. - **Can Rokad migrate data into Zoho CRM or other applications?** Yes. We map fields, relationships, ownership, history, activities, files, duplicates, validation, open transactions, and reporting requirements. - **Can Rokad provide ongoing Zoho support?** Yes. Managed services can cover users, roles, CRM, Creator, functions, workflows, data, integrations, reports, incidents, and continuous improvement. --- ## [Service specialisation] Internal tools development Canonical URL: https://rokad.co/en/services/software-development/internal-tools > Rokad builds purpose-designed internal software that replaces manual coordination, fragmented tooling, and repetitive operational work. Internal tools should reflect the way a team actually works while preserving controls, data quality, and maintainability. Rokad builds operational dashboards, workflow systems, administration consoles, approval tools, data interfaces, reporting platforms, and automation for specific business processes. ### Designed for - **Operations teams constrained by spreadsheets:** Replace fragile manual processes with shared workflows, validation, ownership, history, and reporting. - **Product companies needing operator tooling:** Give support, success, finance, compliance, and operations teams safe control over customer and platform workflows. - **Growing organisations with tool sprawl:** Consolidate disconnected forms, scripts, databases, and SaaS products into a maintainable operational layer. ### Challenges - **Work depends on copy, paste, and memory:** Repetitive coordination creates delays, errors, weak accountability, and limited operational visibility. - **Commercial tools do not match the workflow:** Teams maintain workarounds because generic software cannot represent the required data, rules, or exceptions. - **Operators need access without engineering risk:** Internal teams require controlled actions, auditability, validation, and safe self-service over production systems. ### Capabilities - Operational dashboards, queues, cases, tasks, and approvals - Administrative consoles and safe production actions - Forms, validation, data management, and document workflows - Role-based access, audit history, and segregation controls - Automation, notifications, scheduled work, and exception handling - CRM, ERP, support, finance, database, and API integration - Reporting, analytics, bottleneck, and service-level visibility ### Solution components - **Work management:** Queues, ownership, status, priorities, deadlines, escalation, approvals, and operational context. - **Safe administration:** Validated actions, permissions, confirmation, audit history, reversible operations, and support tooling. - **Data and integration:** Unified views, controlled edits, synchronisation, imports, exports, APIs, and systems-of-record boundaries. - **Operational intelligence:** Volume, ageing, bottlenecks, performance, exceptions, quality, and service-level reporting. ### Use cases - **Customer operations console:** Provide support and success teams with account context, actions, history, communication, and escalation controls. - **Approval and exception workflow:** Coordinate requests, evidence, policy checks, decisions, delegation, deadlines, and audit trails. - **Data operations platform:** Manage imports, validation, review, enrichment, correction, reconciliation, and downstream publication. - **Field-to-office workflow:** Connect distributed data capture, documents, tasks, review, status, and reporting with central operations. ### Architecture and integration - **System-of-record boundaries:** Define which system owns each field and action so the tool improves operations without creating uncontrolled duplicate data. - **Action safety:** Use validation, previews, permissions, confirmation, idempotency, audit, and recovery for production-affecting operations. - **Pragmatic platform choice:** Select custom development, low-code, workflow platforms, or a hybrid based on longevity, complexity, governance, and economics. ### Quality and control - **Secure engineering:** Permissions, data boundaries, secrets, dependencies, threat scenarios, and recovery requirements are addressed throughout delivery. - **Production readiness:** Testing, observability, performance, deployment controls, rollback planning, and operating documentation are included in the definition of done. - **Maintainable ownership:** The client receives structured source code, technical documentation, operating knowledge, and a practical path for future development. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - Workflow and operational discovery - Data, role, action, and integration design - Production internal application and source code - Permissions, audit, validation, and operator controls - Automated tests, deployment, monitoring, and backup - Administrator, user, technical, and operating documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Should we build a custom tool or use low-code software?** We evaluate workflow complexity, integration, security, data volume, maintainability, governance, change frequency, vendor lock-in, and total cost before recommending custom, low-code, configured SaaS, or a hybrid. - **Can internal tools safely access production data?** Yes, with explicit permissions, least-privilege access, validation, audit trails, action safeguards, environment separation, and recovery controls. - **Can Rokad automate the workflow as well?** Yes. The system can include rules, scheduled work, notifications, integrations, document generation, AI-assisted steps, approval gates, and exception handling. - **Can the tool evolve as our process changes?** Yes. We design modular workflows, configuration, data models, tests, and documentation so future changes remain controlled and maintainable. --- ## [Service specialisation] Marketplace platform development Canonical URL: https://rokad.co/en/services/software-development/marketplace-platforms > Rokad develops multi-sided marketplace platforms with participant onboarding, discovery, transactions, commissions, trust, payouts, and operator control. Marketplace software coordinates several participants with different incentives, permissions, data, and risks. Rokad builds product, service, talent, content, procurement, and specialised marketplaces with supply onboarding, listings, matching, transactions, trust mechanisms, dispute handling, and platform operations. ### Designed for - **Companies launching a multi-sided business model:** Build the transaction, trust, liquidity, and operator systems required to connect supply and demand. - **Existing platforms replacing manual operations:** Move onboarding, matching, pricing, fulfilment, communication, payments, and disputes into an integrated platform. - **Industry networks becoming digital markets:** Translate specialised participants, standards, workflows, and commercial rules into a governed marketplace. ### Challenges - **Each side of the market needs a different product:** Buyers, sellers, providers, partners, and operators require distinct journeys, permissions, information, and incentives. - **Transactions require trust and exception handling:** Identity, quality, moderation, payment, fulfilment, disputes, refunds, and reputation must work as one system. - **The operator cannot see or control the market:** Manual intervention lacks safe tooling, auditability, policy controls, investigation context, and performance insight. ### Capabilities - Participant registration, verification, onboarding, and profiles - Listings, catalogues, availability, search, filters, and matching - Offers, bookings, orders, contracts, communication, and workflow - Payments, commissions, fees, escrow patterns, refunds, and payouts - Ratings, reviews, moderation, policy, disputes, and trust systems - Operator console, support, risk, fraud, analytics, and market controls - APIs, partner integrations, notifications, and multi-region operations ### Solution components - **Demand experience:** Discovery, evaluation, transaction, communication, status, support, and repeat participation. - **Supply experience:** Onboarding, verification, listings, availability, pricing, fulfilment, performance, and payouts. - **Transaction and trust layer:** Matching, contracts, payments, commissions, moderation, reputation, disputes, refunds, and evidence. - **Marketplace operations:** Participant support, intervention, policy, risk, fraud, liquidity, quality, analytics, and commercial controls. ### Use cases - **Product marketplace:** Coordinate vendors, catalogue, inventory, orders, commission, fulfilment, returns, and operator oversight. - **Service marketplace:** Manage providers, availability, matching, quotations, bookings, delivery evidence, payment, and review. - **Talent or expert network:** Support profiles, verification, opportunities, applications, matching, contracts, work, and payouts. - **B2B procurement network:** Connect qualified buyers and suppliers through catalogues, requests, offers, approvals, orders, and transaction records. ### Architecture and integration - **Participant and policy model:** Represent roles, organisations, verification, eligibility, market access, jurisdiction, and conditional permissions. - **Transaction state machine:** Model offers, acceptance, payment, delivery, cancellation, refund, dispute, and completion as auditable states. - **Financial ledger and reconciliation:** Track charges, fees, commissions, taxes, refunds, balances, and payouts independently from provider events. ### Quality and control - **Secure engineering:** Permissions, data boundaries, secrets, dependencies, threat scenarios, and recovery requirements are addressed throughout delivery. - **Production readiness:** Testing, observability, performance, deployment controls, rollback planning, and operating documentation are included in the definition of done. - **Maintainable ownership:** The client receives structured source code, technical documentation, operating knowledge, and a practical path for future development. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - Marketplace model, participant, and transaction discovery - Production buyer, seller, provider, and operator applications - Listing, discovery, matching, transaction, and communication workflows - Payment, commission, refund, payout, and reconciliation controls - Trust, moderation, dispute, audit, and support tooling - Analytics, deployment, security, and operating documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad build both sides of the marketplace?** Yes. We design participant-specific experiences plus the shared transaction, identity, trust, communication, payment, and operator systems. - **Can you implement commissions and payouts?** Yes. We can design fee rules, split payments, balances, payout schedules, refunds, disputes, provider integration, reconciliation, and operator controls subject to the selected provider and jurisdiction. - **How do you handle trust and moderation?** The platform can combine verification, eligibility, content rules, ratings, evidence, reporting, review queues, policy actions, appeals, and audit history. - **Can the marketplace start with a narrow segment?** Yes. We often recommend a focused participant group, geography, category, or transaction workflow to validate liquidity and operations before expansion. --- ## [Service specialisation] Legacy software modernisation Canonical URL: https://rokad.co/en/services/software-development/legacy-modernization > Rokad modernises ageing software through controlled assessment, phased architecture change, data migration, infrastructure improvement, and operational continuity. Legacy modernisation is a risk-managed transformation, not simply a rewrite. Rokad documents critical behaviour and dependencies, identifies the sources of cost and fragility, selects an appropriate modernisation pattern, and delivers change while protecting users, data, integrations, and business continuity. ### Designed for - **Organisations dependent on ageing critical systems:** Reduce operational, security, staffing, vendor, and continuity risk without discarding essential business behaviour. - **Product teams slowed by architectural debt:** Improve release speed, reliability, testability, observability, and maintainability while continuing roadmap delivery. - **Companies preparing for scale, compliance, or acquisition:** Address technical and operational weaknesses that limit growth, assurance, diligence, or enterprise adoption. ### Challenges - **Nobody fully understands the system:** Business behaviour, integrations, jobs, data assumptions, and operational procedures are undocumented or concentrated in a few people. - **Every change carries disproportionate risk:** Weak tests, tight coupling, manual releases, ageing dependencies, and missing observability make delivery slow and unsafe. - **A full rewrite is commercially dangerous:** The organisation cannot pause operations or reproduce years of edge cases without phased validation and coexistence. ### Capabilities - Application, architecture, code, infrastructure, data, and operational assessment - Business-behaviour discovery and dependency mapping - Rehost, replatform, refactor, replace, or strangler-pattern planning - Modularisation, API enablement, test foundations, and observability - Cloud, container, database, dependency, and security modernisation - Data migration, coexistence, cutover, rollback, and continuity planning - Delivery pipeline, documentation, ownership, and managed transition ### Solution components - **Current-state evidence:** Code, architecture, data, interfaces, jobs, environments, dependencies, business behaviour, incidents, and operating knowledge. - **Target architecture:** Boundaries, migration pattern, platform decisions, interfaces, quality attributes, controls, and transitional states. - **Incremental transformation:** Prioritised slices that reduce risk, deliver value, validate assumptions, and retire legacy responsibility progressively. - **Operational transition:** Monitoring, release, support, data, runbooks, ownership, training, cutover, rollback, and decommissioning. ### Use cases - **Monolith decomposition:** Introduce boundaries, interfaces, modular deployment, ownership, and tests without unnecessary service fragmentation. - **Cloud and platform modernisation:** Improve deployment, environments, infrastructure, scaling, observability, backup, recovery, and cost control. - **Application replacement:** Rebuild critical workflows on a maintainable foundation with data migration, coexistence, and phased rollout. - **Security and dependency renewal:** Remove unsupported runtimes, libraries, operating systems, databases, protocols, and unsafe operational practices. ### Architecture and integration - **Modernisation pattern:** Select rehost, replatform, refactor, replace, retain, retire, or a staged combination based on evidence and economics. - **Coexistence boundary:** Use APIs, adapters, events, routing, synchronisation, and ownership rules while legacy and modern components operate together. - **Migration safety:** Rehearse data and traffic movement with validation, observability, checkpoints, rollback, and explicit acceptance criteria. ### Quality and control - **Secure engineering:** Permissions, data boundaries, secrets, dependencies, threat scenarios, and recovery requirements are addressed throughout delivery. - **Production readiness:** Testing, observability, performance, deployment controls, rollback planning, and operating documentation are included in the definition of done. - **Maintainable ownership:** The client receives structured source code, technical documentation, operating knowledge, and a practical path for future development. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - Current-state assessment and risk register - Business behaviour, dependency, and data map - Target architecture and modernisation decision record - Prioritised migration roadmap and transition plan - Modernised application, platform, interfaces, or infrastructure - Test, observability, deployment, rollback, and operating controls ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Does modernisation always require a rewrite?** No. Rehosting, replatforming, modular refactoring, dependency renewal, API enablement, selective replacement, and retirement may create better risk-adjusted outcomes than a full rewrite. - **How do you protect business continuity?** We use dependency discovery, phased delivery, coexistence, migration rehearsal, monitoring, validation, rollback, and explicit operational acceptance before retiring legacy responsibility. - **Can Rokad modernise a system with limited documentation?** Yes. We reconstruct behaviour from code, data, integrations, logs, users, operators, tests, incidents, and production observation before making high-risk changes. - **Can you modernise while continuing feature delivery?** Yes. We can separate stabilisation, roadmap work, and architectural transformation into coordinated workstreams with defined boundaries and release controls. --- ## [Service specialisation] API and backend development Canonical URL: https://rokad.co/en/services/software-development/api-backend > Rokad develops secure APIs, backend services, data layers, integrations, event systems, and operational foundations for digital products and business platforms. The backend carries the product's data, rules, integrations, security, reliability, and operating behaviour. Rokad engineers APIs and services that support web, mobile, SaaS, commerce, enterprise, AI, and connected-product requirements with explicit contracts, observability, and long-term maintainability. ### Designed for - **Product teams building a new platform foundation:** Establish secure services, data models, integrations, workflows, and deployment patterns before frontend complexity grows. - **Companies exposing product or partner APIs:** Create stable contracts, authentication, quotas, webhooks, documentation, versioning, and developer operations. - **Organisations integrating fragmented systems:** Coordinate data and workflows across internal applications, vendors, customers, and operational platforms. ### Challenges - **Business logic is duplicated across applications:** Rules and data behaviour diverge because each interface implements its own incomplete version of the system. - **Integrations fail silently or unpredictably:** Missing contracts, retries, idempotency, reconciliation, and observability create operational inconsistency. - **Backend changes are difficult to release safely:** Tight coupling, weak tests, shared data, undocumented APIs, and manual deployment increase product risk. ### Capabilities - REST, GraphQL, event, webhook, and partner APIs - Domain services, workflows, rules, queues, and background processing - Relational, document, search, cache, object, and analytical data systems - Authentication, authorisation, organisations, roles, policy, and audit - Payment, identity, CRM, ERP, communication, AI, and vendor integrations - API gateway, rate limits, versioning, documentation, SDK, and developer experience - Testing, observability, deployment, scaling, backup, recovery, and managed operation ### Solution components - **Domain and data layer:** Models, invariants, transactions, ownership, validation, retention, indexing, and data access patterns. - **API contracts:** Resources, operations, schemas, errors, authentication, pagination, versioning, compatibility, and documentation. - **Asynchronous workflows:** Events, queues, jobs, schedules, retries, idempotency, dead letters, reconciliation, and long-running processes. - **Platform operation:** Configuration, secrets, deployments, telemetry, alerts, capacity, security, backup, recovery, and incident diagnosis. ### Use cases - **Product backend:** Power web and mobile interfaces with identity, data, workflow, notifications, payments, and administration. - **Partner integration API:** Expose stable, secure, documented capabilities with onboarding, credentials, quotas, webhooks, and support tooling. - **Integration and orchestration layer:** Coordinate operational data and workflows across ERP, CRM, finance, support, warehouse, vendor, and internal systems. - **Backend modernisation:** Separate business logic, introduce contracts, improve data boundaries, automate delivery, and establish observability. ### Architecture and integration - **Modular boundaries:** Organise services and code around business capabilities and ownership rather than premature technology fragmentation. - **Consistency model:** Define transaction, event, retry, reconciliation, and user-experience behaviour where work crosses systems. - **Compatibility strategy:** Use explicit contracts, versioning, migrations, deprecation, and consumer testing to change APIs safely. ### Quality and control - **Secure engineering:** Permissions, data boundaries, secrets, dependencies, threat scenarios, and recovery requirements are addressed throughout delivery. - **Production readiness:** Testing, observability, performance, deployment controls, rollback planning, and operating documentation are included in the definition of done. - **Maintainable ownership:** The client receives structured source code, technical documentation, operating knowledge, and a practical path for future development. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - Backend architecture, domain, data, and integration plan - Production APIs, services, workflows, and source code - Database schemas, migrations, indexes, and data controls - Authentication, authorisation, audit, rate, and security controls - Automated tests, API documentation, and integration examples - Deployment, observability, backup, recovery, and operating documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad build only the backend for our existing product team?** Yes. We can own defined APIs, services, data, integrations, platform foundations, or backend modernisation while coordinating contracts with your frontend and product teams. - **Do we need microservices?** Not necessarily. We select modular monolith, services, functions, events, or a hybrid based on team boundaries, scale, deployment independence, reliability, data ownership, and operational cost. - **Can you integrate with legacy or vendor systems?** Yes. We use adapters, APIs, files, queues, events, scheduled synchronisation, reconciliation, and observability according to the available interface and reliability requirements. - **Do you provide API documentation and developer onboarding?** Yes. Deliverables can include OpenAPI or GraphQL schemas, examples, authentication guidance, error contracts, webhooks, SDKs, sandbox environments, credentials, and support workflows. --- ## [Service specialisation] Automation and integration development Canonical URL: https://rokad.co/en/services/software-development/automation > Rokad designs and builds dependable business automation across SaaS platforms, APIs, databases, documents, enterprise systems, desktop applications, and AI-assisted workflows. Automation creates value when the complete business process—including exceptions, approvals, data ownership, reconciliation, security, and human intervention—is engineered deliberately. Rokad maps the operation, selects the appropriate automation platform or custom architecture, implements governed workflows, and establishes monitoring and long-term ownership. ### Designed for - **Operations teams constrained by repetitive coordination:** Automate recurring data entry, routing, notifications, document handling, approvals, reconciliation, and cross-system updates. - **Product and engineering teams integrating fragmented systems:** Connect SaaS products, internal applications, APIs, databases, events, files, and AI capabilities without creating brittle point-to-point scripts. - **Enterprises governing citizen and departmental automation:** Introduce environments, ownership, access, reusable components, monitoring, change controls, and platform standards across teams. ### Challenges - **The happy path works but exceptions become manual:** Duplicates, missing data, approval delays, third-party failures, retries, partial completion, and reconciliation are not designed into the workflow. - **Automations depend on personal accounts and undocumented knowledge:** Credentials, connections, ownership, folders, naming, environments, test data, and support procedures are tied to individuals. - **Automation volume grows without operational visibility:** Teams cannot see run health, failures, business impact, latency, usage, cost, data quality, or which process owner must respond. ### Capabilities - Business-process, user, system, data, exception, and control discovery - Zapier, Make, n8n, Power Automate, Workato, and UiPath implementation - API, webhook, event, database, file, email, SaaS, and enterprise integration - Custom connectors, platform applications, reusable actions, and middleware - Approvals, human review, queues, schedules, routing, and escalation - Document extraction, AI-assisted classification, drafting, and decision support - Idempotency, retry, reconciliation, error handling, audit, and recovery - Monitoring, alerts, environments, access, documentation, and managed automation ### Solution components - **Process and control model:** Actors, triggers, states, decisions, approvals, exceptions, service targets, evidence, ownership, and fallback procedures. - **Integration layer:** Connectors, APIs, webhooks, events, files, databases, transformations, mapping, identity, and system-of-record boundaries. - **Execution and recovery:** Queues, schedules, concurrency, idempotency, retries, timeouts, checkpoints, reconciliation, compensation, and manual intervention. - **Automation operations:** Environments, credentials, ownership, versioning, monitoring, alerts, cost, audit, support, documentation, and lifecycle. ### Use cases - **Lead-to-customer automation:** Coordinate forms, enrichment, CRM, routing, communication, proposals, approvals, onboarding, billing, and reporting. - **Finance and operations workflows:** Automate document intake, validation, reconciliation, approval, status, exceptions, notifications, and system updates. - **Customer and employee service automation:** Connect requests, knowledge, classification, ticketing, approvals, fulfilment, communication, and escalation. - **Product and data integration:** Synchronise applications, transform records, trigger product workflows, publish events, and maintain reliable cross-system state. ### Architecture and integration - **Platform selected by process risk:** Choose visual automation, enterprise iPaaS, self-hosted orchestration, RPA, or custom software from latency, volume, control, data, and ownership needs. - **System-of-record boundaries:** Define which application owns each entity and field, how updates flow, how conflicts resolve, and how drift is reconciled. - **Human intervention is designed:** Provide visible queues, approval context, correction paths, escalation, reprocessing, and audit rather than relying on informal workarounds. ### Quality and control - **Secure by design:** Identity, permissions, secrets, data boundaries, dependencies, change controls, and recovery are addressed throughout delivery. - **Observable operation:** Metrics, logs, traces, quality, cost, failures, and service outcomes are made visible and actionable. - **Reproducible delivery:** Configuration, tests, infrastructure, pipelines, artefacts, changes, and recovery procedures are versioned and repeatable. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Process, system, data, exception, and automation-opportunity assessment - Platform selection, integration architecture, and control design - Production workflows, connectors, APIs, middleware, or desktop automations - Validation, transformation, retry, reconciliation, approval, and recovery controls - Monitoring, alerts, dashboards, environments, access, and operating workflows - Process, technical, administrator, support, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Which automation platform should we use?** The decision depends on systems, APIs, desktop requirements, volume, latency, data sensitivity, governance, self-hosting, developer access, licensing, and long-term ownership. Rokad documents the trade-offs before implementation. - **Can Rokad automate systems without APIs?** Where justified, desktop automation, browser interaction, email, files, database access, document processing, or controlled adapters may be used. These approaches require stronger failure and change controls than supported APIs. - **Can AI be included in an automation?** Yes. AI can classify, extract, summarise, draft, recommend, or route work, with evaluation, permissions, confidence thresholds, human review, and fallback matched to business risk. - **Can Rokad take over existing workflows?** Yes. We audit connections, ownership, credentials, logic, run history, failures, volume, cost, documentation, and business impact before stabilising and transferring operation. --- ## [Platform service] Zapier automation services Canonical URL: https://rokad.co/en/services/software-development/automation/zapier Platform: Zapier > Rokad designs, builds, audits, and manages Zapier automations across SaaS applications, webhooks, data, approvals, interfaces, and custom integrations. Zapier is effective for rapidly connecting business applications and coordinating operational workflows. Rokad moves implementations beyond isolated trigger-action recipes by defining system ownership, data transformations, paths, delays, approvals, error handling, reconciliation, credentials, environments, monitoring, and support. ### Designed for - **Growing teams replacing repetitive SaaS coordination:** Automate lead handling, onboarding, notifications, records, documents, fulfilment, reporting, and internal handoffs. - **Operations teams with unmanaged Zaps:** Consolidate personal automations into documented, owned, observable, and supportable business workflows. - **Product teams extending Zapier with custom systems:** Connect private APIs, webhooks, internal applications, databases, and reusable custom actions. ### Implementation risks - **Multi-step Zaps fail after partial completion:** Records are created in some systems but not others because idempotency, retry, compensation, and reconciliation are missing. - **Personal connections become production dependencies:** Credentials, account ownership, folders, naming, test data, and recovery rely on individual employees. - **Task usage grows faster than business value:** Polling, loops, duplicate runs, poor filters, unnecessary steps, and fragmented workflows increase cost and noise. ### Platform capabilities - Zap and business-process design, audit, consolidation, and documentation - Triggers, actions, filters, paths, delays, loops, formatters, schedules, and sub-workflows - Webhooks, REST APIs, custom requests, private applications, and custom platform actions - Zapier Tables, Interfaces, forms, operator tools, approvals, and lightweight internal applications - CRM, marketing, sales, support, finance, ecommerce, productivity, and data integrations - AI-assisted extraction, classification, drafting, routing, and tool-enabled workflows - Failure alerts, retries, reconciliation, task optimisation, credentials, ownership, and managed support ### Implementation system - **Zap portfolio:** Process inventory, owners, folders, naming, triggers, systems, task volume, criticality, and support expectations. - **Integration logic:** Fields, transformations, paths, filters, lookups, deduplication, webhooks, APIs, and system-of-record rules. - **Human workflow:** Forms, Interfaces, Tables, approvals, correction queues, notifications, escalation, and controlled reprocessing. - **Production operation:** Connections, permissions, alerts, run review, usage, cost, documentation, incident response, and change control. ### Use cases - **Lead and revenue operations:** Connect forms, enrichment, CRM, assignment, outreach, proposals, meetings, billing, and reporting. - **Customer onboarding:** Coordinate contracts, payments, accounts, workspaces, tasks, communications, documents, and internal approvals. - **Ecommerce operations:** Synchronise orders, inventory signals, support, fulfilment, finance, notifications, reviews, and customer data. - **Internal request systems:** Use Interfaces and Tables for controlled intake, routing, status, approvals, records, and operational follow-up. ### Architecture - **One owner per business process:** Group related Zaps, Tables, Interfaces, credentials, documentation, alerts, and support under an accountable process owner. - **Webhook-first where latency matters:** Prefer event-driven triggers over polling when supported, with authentication, deduplication, replay, and rate-limit controls. - **Custom middleware for complex state:** Move high-volume, transactional, deeply stateful, or sensitive logic into software services while Zapier orchestrates business steps. ### Quality and governance - **Controlled business actions:** Permissions, approvals, idempotency, retry, reconciliation, audit, and rollback are defined for workflows that change business systems. - **Observable execution:** Triggers, runs, failures, latency, volume, cost, credentials, and downstream impact are visible to operators. - **Maintainable ownership:** Naming, folders, environments, documentation, test data, connection ownership, versioning, and support procedures are established. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Zapier workflow and account audit - Process, field, integration, ownership, and exception design - Production Zaps, Tables, Interfaces, webhooks, and custom actions - Validation, retry, deduplication, reconciliation, and failure controls - Task-usage, performance, monitoring, alerting, and cost improvements - Administrator, operator, support, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad build a private Zapier integration for our software?** Yes. We can expose or consume APIs, define authentication, triggers, actions, searches, fields, errors, pagination, and versioning, then support testing and rollout. - **Can existing Zaps be audited and consolidated?** Yes. We review business purpose, owners, connections, task volume, logic, duplicates, failures, security, documentation, and opportunities to combine or retire workflows. - **When should Zapier be replaced with custom software?** Custom services become appropriate when workflows require high volume, strict latency, complex transactions, extensive state, specialised security, or economics that no longer fit task-based automation. - **Can Rokad manage Zapier after launch?** Yes. Managed support can cover failures, connection changes, field changes, new workflows, usage, cost, documentation, access, and platform updates. --- ## [Platform service] Make automation services Canonical URL: https://rokad.co/en/services/software-development/automation/make Platform: Make > Rokad designs and implements Make scenarios for complex visual workflow automation, API integration, data transformation, AI-assisted processes, and operational control. Make is well suited to workflows that benefit from visible data flow, branching, transformation, iteration, aggregation, webhooks, and broad application connectivity. Rokad structures scenarios around reusable process boundaries, reliable state, error handlers, rate limits, data stores, observability, and clear operator ownership. ### Designed for - **Operations teams with multi-branch workflows:** Coordinate records, documents, approvals, transformations, notifications, and exceptions across several systems. - **Technical teams requiring visual API orchestration:** Connect public and custom APIs with webhooks, HTTP requests, custom code, data stores, and reusable scenarios. - **Companies scaling Make beyond departmental experiments:** Introduce team structure, environments, connections, naming, templates, monitoring, governance, and support. ### Implementation risks - **Large scenarios become difficult to reason about:** Business logic, transformation, retries, branches, and exceptions accumulate in one visual canvas without modular boundaries. - **Bundles create unexpected duplication or cost:** Iterators, searches, aggregators, routers, polling, and repeated API calls multiply operations and produce inconsistent records. - **Error handlers do not restore business consistency:** A technical retry may rerun unsafe actions or leave downstream systems partially updated without reconciliation. ### Platform capabilities - Make scenario architecture, review, refactoring, templates, and reusable sub-scenarios - Instant and scheduled webhooks, routers, filters, iterators, aggregators, variables, and data stores - HTTP, REST, GraphQL, OAuth, custom applications, and unsupported API integrations - JavaScript or Python functions for specialised transformation and validation - CRM, ecommerce, finance, support, marketing, data, productivity, and document workflows - AI agents and AI-assisted extraction, classification, generation, routing, and review - Error handlers, incomplete executions, retries, rate limits, idempotency, monitoring, and operation optimisation ### Implementation system - **Scenario architecture:** Process boundaries, triggers, routes, reusable scenarios, variables, data stores, inputs, outputs, and ownership. - **Data transformation:** Mapping, parsing, arrays, iteration, aggregation, validation, normalisation, enrichment, and schema boundaries. - **API coordination:** Authentication, pagination, rate limits, webhooks, polling, retries, timeouts, custom requests, and response handling. - **Operational controls:** Connections, teams, environments, logs, alerts, incomplete runs, reprocessing, cost, documentation, and support. ### Use cases - **Complex SaaS orchestration:** Coordinate several applications through branching, transformations, lookups, approvals, and controlled exception paths. - **Document and content pipelines:** Ingest files, extract data, transform content, apply AI, route review, publish outputs, and maintain evidence. - **Commerce and fulfilment automation:** Synchronise products, orders, customers, inventory, shipping, finance, support, and partner systems. - **API-led operational workflows:** Use Make as a visible orchestration layer around custom APIs, internal services, webhooks, and databases. ### Architecture - **Modular scenarios:** Separate intake, validation, business decisions, integrations, notification, and recovery into understandable reusable units. - **Bundle economics are measured:** Design filters, searches, iterations, aggregation, batching, schedules, and data access around real operation volume and cost. - **Recovery follows business state:** Track checkpoints and external identifiers so retries and reprocessing restore consistency without duplicating irreversible actions. ### Quality and governance - **Controlled business actions:** Permissions, approvals, idempotency, retry, reconciliation, audit, and rollback are defined for workflows that change business systems. - **Observable execution:** Triggers, runs, failures, latency, volume, cost, credentials, and downstream impact are visible to operators. - **Maintainable ownership:** Naming, folders, environments, documentation, test data, connection ownership, versioning, and support procedures are established. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Make organisation, scenario, connection, operation, and failure audit - Process, scenario, API, data, exception, and ownership architecture - Production scenarios, custom integrations, data stores, functions, and AI workflows - Validation, error handling, retry, rate-limit, reconciliation, and reprocessing controls - Operation usage, performance, logs, alerting, and cost optimisation - Technical, operator, administrator, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Make connect to an API without a native integration?** Yes. We can use HTTP modules, webhooks, OAuth or other authentication, pagination, custom applications, and JavaScript or Python functions where appropriate. - **Can a large Make scenario be refactored?** Yes. We can split responsibilities, introduce reusable scenarios, reduce repeated operations, clarify routes, improve error handling, and document inputs and outputs. - **How do you control Make operation usage?** We analyse schedules, polling, filters, search volume, bundle counts, loops, repeated calls, caching, batching, and scenario boundaries against business requirements. - **Can Rokad manage Make workflows after launch?** Yes. Support can include failed runs, connection changes, schema changes, scenario updates, monitoring, usage, cost, documentation, and new automation work. --- ## [Platform service] n8n automation development Canonical URL: https://rokad.co/en/services/software-development/automation/n8n Platform: n8n > Rokad develops and operates n8n automation for technical teams requiring flexible workflows, self-hosting, custom nodes, private integrations, and AI orchestration. n8n provides a strong fit where teams need visual orchestration together with infrastructure control, custom code, private-network access, reusable workflows, and technical extensibility. Rokad designs workflow boundaries, hosting, credentials, execution, custom nodes, AI tools, observability, scaling, and lifecycle management. ### Designed for - **Technical teams requiring self-hosted automation:** Keep workflow execution and credentials inside controlled cloud, private, or hybrid infrastructure. - **Product teams embedding sophisticated integrations:** Build APIs, webhooks, reusable sub-workflows, custom nodes, data processing, and product-triggered automation. - **AI teams orchestrating tools and business systems:** Connect models, agents, retrieval, human approval, applications, databases, and observable actions. ### Implementation risks - **Self-hosting transfers operational responsibility:** Availability, databases, queues, workers, storage, credentials, upgrades, backups, logs, security, and recovery need explicit ownership. - **Workflow flexibility creates inconsistent engineering:** Code nodes, credentials, naming, data structures, retries, environment values, and workflow boundaries vary by author. - **AI workflows can take uncontrolled actions:** Tool permissions, context, model behaviour, approvals, audit, retries, and downstream changes require governance. ### Platform capabilities - n8n Cloud, self-hosted, container, Kubernetes, database, queue, worker, and network architecture - Webhook, schedule, event, API, database, file, queue, and application workflows - Reusable sub-workflows, code nodes, custom nodes, credentials, variables, and templates - Private APIs, internal services, databases, VPN, gateway, and on-premises integration - AI agents, models, retrieval, tools, memory, human review, and workflow orchestration - Execution data, retries, error workflows, idempotency, concurrency, rate limits, and recovery - Monitoring, logging, backup, upgrades, security, performance, scaling, and managed operation ### Implementation system - **n8n platform:** Hosting, database, queue, workers, encryption, credentials, storage, networking, domains, backup, and upgrades. - **Workflow engineering:** Triggers, schemas, transformations, reusable units, code, custom nodes, tests, errors, inputs, and outputs. - **AI and integration layer:** Models, tools, retrieval, APIs, databases, webhooks, internal services, approvals, and application boundaries. - **Operational governance:** Projects, environments, credentials, access, execution retention, telemetry, incidents, releases, and documentation. ### Use cases - **Private business automation platform:** Run governed workflows across internal applications, databases, SaaS systems, files, events, and approvals. - **AI agent orchestration:** Connect models to authorised tools and data with evaluation, approvals, audit, fallbacks, and recovery. - **Product integration backend:** Receive application events, call APIs, process data, trigger jobs, notify users, and coordinate external systems. - **Data and document workflows:** Ingest, validate, transform, enrich, classify, review, route, store, and reconcile records and files. ### Architecture - **Separate platform and workflow ownership:** Define who operates n8n infrastructure and who owns each business workflow, credential, integration, and support outcome. - **Queue execution for scalable workloads:** Use controlled worker concurrency, backpressure, database capacity, execution retention, timeouts, and autoscaling where volume requires it. - **Custom nodes for repeated domain logic:** Move common authentication, validation, pagination, errors, and actions out of copied code nodes into versioned components. ### Quality and governance - **Controlled business actions:** Permissions, approvals, idempotency, retry, reconciliation, audit, and rollback are defined for workflows that change business systems. - **Observable execution:** Triggers, runs, failures, latency, volume, cost, credentials, and downstream impact are visible to operators. - **Maintainable ownership:** Naming, folders, environments, documentation, test data, connection ownership, versioning, and support procedures are established. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - n8n platform, workflow, credential, execution, security, and risk assessment - Hosting, network, database, queue, worker, backup, and recovery architecture - Production workflows, sub-workflows, code, custom nodes, and integrations - AI tool, permission, approval, evaluation, observability, and audit controls - Monitoring, logging, alerting, scaling, upgrade, and incident workflows - Developer, administrator, operator, security, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad self-host n8n for us?** Yes. We can design and implement container or Kubernetes hosting, database, queues, workers, storage, networking, identity, backups, monitoring, upgrades, and operating procedures. - **Can Rokad build custom n8n nodes?** Yes. Custom nodes can package authentication, resources, operations, fields, pagination, errors, polling, triggers, and reusable domain logic for internal or public integrations. - **Can n8n be used for AI agents?** Yes. We can orchestrate models, retrieval, memory, tools, structured outputs, approvals, and application actions with evaluation and business-risk controls. - **Can Rokad migrate workflows from Zapier or Make?** Yes. We map triggers, actions, data, connections, errors, schedules, volume, business ownership, and platform-specific behaviour before rebuilding and validating workflows. --- ## [Platform service] Microsoft Power Automate services Canonical URL: https://rokad.co/en/services/software-development/automation/microsoft-power-automate Platform: Microsoft Power Automate > Rokad develops and governs Microsoft Power Automate cloud and desktop automation across Microsoft 365, Dataverse, Dynamics 365, enterprise applications, and legacy systems. Power Automate can coordinate Microsoft 365 and business applications through cloud flows, while desktop flows extend automation into user interfaces and legacy systems. Rokad designs solutions, environments, connectors, gateways, identities, approvals, RPA machines, monitoring, deployment, and lifecycle governance. ### Designed for - **Microsoft 365 and Dynamics organisations:** Automate SharePoint, Teams, Outlook, Excel, Forms, Dataverse, Dynamics 365, approvals, notifications, and records. - **Enterprises automating legacy desktop processes:** Use attended or unattended desktop flows where supported APIs and integrations are unavailable. - **IT teams governing citizen automation:** Establish environments, solutions, connectors, data policies, service identities, deployment, support, and platform standards. ### Implementation risks - **Flows are created outside managed solutions:** Connections, environment variables, ownership, dependencies, deployment, rollback, and change records become difficult to control. - **Desktop automation depends on unstable interfaces:** Screen layout, selectors, sessions, pop-ups, files, machine state, credentials, and application updates cause unpredictable failures. - **Personal accounts execute business-critical processes:** Employee departure, password changes, licensing, permissions, and mailbox ownership interrupt production workflows. ### Platform capabilities - Cloud flows, instant, automated, scheduled, approval, child-flow, and solution-aware design - Power Automate Desktop attended and unattended RPA implementation - Microsoft 365, Teams, SharePoint, Outlook, Excel, Forms, Dataverse, and Dynamics integration - Standard, premium, custom, on-premises gateway, API, and desktop connectors - Solutions, environment variables, connection references, service identities, and deployment pipelines - Data policies, environments, roles, credentials, machine groups, queues, monitoring, and governance - Process mining, document workflows, AI-assisted automation, testing, support, and managed operation ### Implementation system - **Power Platform environment model:** Tenants, environments, solutions, Dataverse, policies, roles, connections, variables, ownership, and lifecycle. - **Cloud orchestration:** Triggers, connectors, approvals, child flows, HTTP, validation, retries, concurrency, data, and business state. - **Desktop automation:** Machines, sessions, selectors, applications, files, credentials, queues, attended or unattended operation, and recovery. - **Enterprise operation:** Deployment, monitoring, alerts, logs, licensing, support, audits, updates, standards, and centre-of-excellence practices. ### Use cases - **Microsoft 365 process automation:** Coordinate forms, lists, documents, email, Teams, approvals, files, calendars, records, and notifications. - **Dynamics and Dataverse workflows:** Automate customer, sales, service, finance, case, approval, data, and integration processes. - **Legacy desktop RPA:** Operate supported Windows applications, browser interfaces, files, terminals, and repetitive user tasks under control. - **Enterprise automation governance:** Inventory flows, establish environments, policies, ownership, solutions, deployment, monitoring, and support. ### Architecture - **Solutions for production assets:** Package flows, connection references, environment variables, Dataverse components, and dependencies for controlled deployment. - **API before UI automation:** Prefer supported connectors and APIs; use desktop flows where necessary with stronger monitoring, selectors, machine, and recovery controls. - **Non-personal production identity:** Use suitable service accounts, application identities, shared ownership, licensing, and access review for critical processes. ### Quality and governance - **Controlled business actions:** Permissions, approvals, idempotency, retry, reconciliation, audit, and rollback are defined for workflows that change business systems. - **Observable execution:** Triggers, runs, failures, latency, volume, cost, credentials, and downstream impact are visible to operators. - **Maintainable ownership:** Naming, folders, environments, documentation, test data, connection ownership, versioning, and support procedures are established. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Power Automate tenant, environment, flow, connection, machine, and licensing assessment - Solution, connector, gateway, identity, data, desktop, and governance architecture - Production cloud flows, desktop flows, custom connectors, approvals, and integrations - Environment variables, connection references, deployment, test, and rollback workflows - Monitoring, queues, alerts, credentials, machine, failure, and support controls - Maker, administrator, operator, security, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Power Automate connect to on-premises systems?** Yes, where supported through the on-premises data gateway, APIs, custom connectors, files, databases, or desktop automation, subject to network and security design. - **Can Rokad automate desktop applications?** Yes. We design attended or unattended desktop flows with machine, session, selector, credential, exception, monitoring, and recovery controls. - **Can existing flows be moved into managed solutions?** Often yes. We inventory dependencies, connection references, environment values, ownership, child flows, Dataverse components, and deployment requirements before migration. - **Can Rokad establish Power Platform governance?** Yes. Scope can include environments, data policies, connectors, roles, service accounts, inventory, standards, deployment, monitoring, support, and centre-of-excellence practices. --- ## [Platform service] Workato integration and automation services Canonical URL: https://rokad.co/en/services/software-development/automation/workato Platform: Workato > Rokad designs and implements governed Workato recipes, custom connectors, enterprise integrations, data orchestration, and operating controls. Workato is designed for enterprise orchestration across applications, data, APIs, workflows, and increasingly AI-enabled actions. Rokad structures projects, recipes, connections, environments, reusable components, custom connectors, on-premises access, error handling, governance, monitoring, and release operations. ### Designed for - **Enterprises standardising integration and automation:** Create governed reusable orchestration across CRM, ERP, HR, finance, support, data, productivity, and custom systems. - **IT and business teams sharing an automation platform:** Balance low-code delivery with security, projects, environments, permissions, reusable assets, and central oversight. - **Organisations connecting cloud and private systems:** Use supported connectors, APIs, custom SDK development, and controlled on-premises connectivity. ### Implementation risks - **Recipes duplicate logic across departments:** Authentication, lookup, mapping, error, notification, and business rules are copied rather than packaged as reusable assets. - **Enterprise integrations lack transaction ownership:** Partial updates, duplicate events, late data, failed jobs, and reconciliation do not have an accountable operating process. - **Business access and IT control are poorly balanced:** Teams either wait on central delivery or create unmanaged recipes, connections, data movement, and production dependencies. ### Platform capabilities - Workato workspace, project, environment, connection, permission, and governance design - Recipe architecture, callable recipes, reusable functions, lookup tables, and shared assets - CRM, ERP, HRIS, finance, support, productivity, data, file, and custom-system integration - REST, GraphQL, webhook, database, file, custom connector SDK, and connector extension development - On-premises agent, private application, network, credential, and enterprise connectivity - API, data, event, batch, business-process, and AI action orchestration - RecipeOps, monitoring, jobs, errors, retries, reconciliation, releases, and managed support ### Implementation system - **Workspace and governance:** Projects, folders, environments, roles, connections, policies, reusable assets, approvals, and delivery standards. - **Recipe architecture:** Triggers, callable units, transformations, lookups, transactions, errors, retries, jobs, and business ownership. - **Connector estate:** Native connectors, custom SDK connectors, REST, private systems, authentication, schemas, actions, and lifecycle. - **Orchestration operations:** RecipeOps, monitoring, alerts, job retention, incident response, reconciliation, releases, usage, and audit. ### Use cases - **Lead-to-cash orchestration:** Coordinate CRM, configure-price-quote, contracts, finance, ERP, billing, fulfilment, support, and reporting. - **Hire-to-retire automation:** Connect HRIS, identity, devices, payroll, access, facilities, training, communications, and offboarding. - **Enterprise data synchronisation:** Move and reconcile records across systems with ownership, batching, event, error, and audit controls. - **Governed AI actions:** Expose approved enterprise processes and application actions to AI systems through controlled orchestration. ### Architecture - **Reusable recipes as platform products:** Package common business capabilities with stable inputs, outputs, errors, ownership, documentation, and version expectations. - **Enterprise transaction boundaries:** Track source identifiers, correlation, idempotency, retries, compensation, reconciliation, and status across participating systems. - **Governed connector extension:** Use the Connector SDK or REST capabilities with controlled authentication, schemas, pagination, errors, tests, and lifecycle. ### Quality and governance - **Controlled business actions:** Permissions, approvals, idempotency, retry, reconciliation, audit, and rollback are defined for workflows that change business systems. - **Observable execution:** Triggers, runs, failures, latency, volume, cost, credentials, and downstream impact are visible to operators. - **Maintainable ownership:** Naming, folders, environments, documentation, test data, connection ownership, versioning, and support procedures are established. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Workato workspace, recipe, connection, job, usage, and governance assessment - Enterprise process, integration, data, connector, and operating architecture - Production recipes, callable recipes, custom connectors, APIs, and reusable assets - Error, retry, idempotency, reconciliation, monitoring, and audit controls - Environment, release, RecipeOps, permission, incident, and support workflows - Developer, administrator, process-owner, security, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad build custom Workato connectors?** Yes. We can implement authentication, triggers, actions, searches, schemas, pagination, webhooks, errors, tests, and documentation using supported connector-development capabilities. - **Can Workato connect to private or on-premises systems?** Yes, subject to supported agents, network design, credentials, firewall, availability, security, and the target system's interfaces. - **Can existing Workato recipes be reviewed?** Yes. We review business ownership, architecture, reuse, connections, errors, job history, volume, data, permissions, documentation, and operating controls. - **Can Rokad provide ongoing Workato operation?** Yes. Managed services can cover jobs, failures, connections, changes, releases, new recipes, connector updates, monitoring, governance, and platform improvement. --- ## [Platform service] UiPath automation services Canonical URL: https://rokad.co/en/services/software-development/automation/uipath Platform: UiPath > Rokad designs, develops, stabilises, and operates UiPath automation across desktop applications, documents, enterprise workflows, robots, orchestration, and human validation. UiPath is appropriate where processes cross desktop interfaces, browsers, documents, terminals, enterprise systems, and human decisions. Rokad analyses automation suitability, develops robust workflows, structures Orchestrator assets and queues, designs attended or unattended robot operation, and establishes monitoring, support, governance, and change control. ### Designed for - **Enterprises automating legacy applications:** Operate desktop, browser, terminal, virtualised, file, email, and document workflows where APIs are limited. - **Shared-service and operations teams:** Automate high-volume finance, HR, customer, compliance, procurement, and back-office processes with queues and controls. - **Organisations stabilising an RPA programme:** Improve robot reliability, selectors, queues, assets, environments, monitoring, support, standards, and governance. ### Implementation risks - **UI changes break production robots:** Selectors, windows, sessions, virtual environments, screen state, timing, pop-ups, and application updates create fragile dependencies. - **Unattended runs lack business recovery:** Failed transactions, partial updates, documents, credentials, queues, and downstream actions cannot be safely replayed. - **Automation candidates are selected by repetition alone:** Process stability, exception rate, data quality, application change, risk, controls, and total operating cost are overlooked. ### Platform capabilities - Process discovery, suitability, exception, control, volume, and automation-value assessment - UiPath Studio and Studio Web workflow design, reusable libraries, and coding standards - Attended, unattended, background, desktop, browser, terminal, file, email, and application automation - Orchestrator folders, machines, robots, queues, assets, credentials, schedules, logs, and alerts - Document Understanding, extraction, classification, validation, and Action Center workflows - API, database, enterprise application, custom activity, and integration development - Testing, deployment, monitoring, support, upgrades, governance, and managed RPA operation ### Implementation system - **Process and transaction model:** Cases, inputs, queues, states, rules, exceptions, evidence, service targets, human decisions, and reconciliation. - **Robot implementation:** Workflows, libraries, selectors, applications, files, APIs, credentials, retries, screenshots, logging, and recovery. - **Orchestrator operation:** Folders, roles, machines, robots, queues, assets, schedules, packages, logs, alerts, environments, and releases. - **Human and document layer:** Document classification, extraction, validation, Action Center tasks, approvals, corrections, and audit evidence. ### Use cases - **Finance operations RPA:** Automate invoice, payment, reconciliation, report, journal, vendor, exception, and approval processes. - **Document processing:** Classify documents, extract fields, validate confidence, route human review, update systems, and retain evidence. - **Legacy system automation:** Operate desktop or browser systems while coordinating files, email, databases, APIs, and downstream applications. - **Employee-assisted automation:** Use attended robots to guide users, collect context, perform repetitive steps, and preserve human judgement. ### Architecture - **Queue-oriented transactions:** Represent work items with identifiers, state, retry, evidence, priority, deadlines, and reconciliation for reliable unattended execution. - **Stable interfaces before selectors:** Prefer APIs and structured integrations where available; use resilient selectors, anchors, state checks, and screenshots for UI automation. - **Robot environment is part of the system:** Control machines, images, applications, patches, sessions, resolution, credentials, network, licences, and application versions. ### Quality and governance - **Controlled business actions:** Permissions, approvals, idempotency, retry, reconciliation, audit, and rollback are defined for workflows that change business systems. - **Observable execution:** Triggers, runs, failures, latency, volume, cost, credentials, and downstream impact are visible to operators. - **Maintainable ownership:** Naming, folders, environments, documentation, test data, connection ownership, versioning, and support procedures are established. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - UiPath process, candidate, application, exception, control, and value assessment - Robot, queue, Orchestrator, document, human-review, and operating architecture - Production workflows, libraries, robots, queues, assets, and integrations - Document extraction, validation, Action Center, and exception workflows - Deployment, testing, monitoring, alerting, support, and recovery controls - Developer, operator, process-owner, infrastructure, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Should a process use attended or unattended robots?** The choice depends on human judgement, credentials, application access, transaction volume, timing, exception handling, workstation context, risk, and licensing. - **Can UiPath process invoices and other documents?** Yes. We can design classification, extraction, confidence thresholds, human validation, business rules, system updates, exception handling, and evidence retention. - **Can Rokad stabilise existing UiPath robots?** Yes. We review selectors, waits, applications, queues, assets, logs, exceptions, machines, credentials, versions, packages, monitoring, and business recovery. - **Can Rokad operate the UiPath environment after delivery?** Yes. Managed support can cover robots, queues, failures, machines, schedules, assets, credentials, packages, upgrades, monitoring, and new automation. --- ## [Service] AI development Canonical URL: https://rokad.co/en/services/ai-development > Dependable AI systems with evaluation, security, observability, and human control built in. Rokad builds AI-native applications, agents, generative workflows, retrieval systems, machine-learning capabilities, computer-vision systems, model integrations, and MLOps foundations. The focus is measurable utility, controlled behaviour, production reliability, and responsible operation. ### Capabilities - AI product discovery and feasibility - Agent and workflow orchestration - RAG, search, and enterprise knowledge systems - Model, provider, tool, and application integration - Machine-learning and computer-vision pipelines - Evaluation, tracing, guardrails, approvals, and MLOps ### Challenges - **An AI concept lacks a production path:** Translate a promising demonstration into a secure, measurable, observable, and maintainable system. - **AI outputs cannot be trusted operationally:** Introduce evaluation, grounding, permissions, policy checks, approval gates, fallbacks, and auditability. - **Knowledge and workflows remain inaccessible:** Connect models to governed enterprise information, tools, and business processes without surrendering control. ### Service scope - **Feasibility and system design:** Define the task, evidence, model strategy, data requirements, risks, evaluation plan, and human-control model. - **AI application engineering:** Build interfaces, orchestration, retrieval, tool use, integrations, data pipelines, and operational controls. - **Evaluation and operation:** Establish quality datasets, automated evaluations, observability, cost controls, release gates, and continuous improvement. ### Use cases - **Knowledge and research assistants:** Provide grounded answers, synthesis, and source access across governed private information. - **Controlled workflow automation:** Allow AI to analyse, draft, recommend, route, or act through approved tools and business rules. - **AI capabilities inside an existing product:** Add generation, extraction, classification, recommendation, search, or conversational functionality. - **Predictive and visual intelligence:** Apply machine learning or computer vision to forecasting, detection, scoring, inspection, and decision support. ### Delivery process - **Discover:** Clarify the business objective, users, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, delivery plan, integrations, security controls, and operating model before implementation. - **Build and validate:** Deliver in controlled increments with review, automated testing, documentation, and stakeholder validation. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence. ### Engineering standards - **Evaluation before automation:** Quality criteria, representative datasets, failure modes, and release thresholds are defined before expanding autonomy. - **Control over side effects:** Permissions, policy checks, approval gates, idempotency, audit trails, and escalation paths govern consequential actions. - **Observable AI operation:** Inputs, outputs, retrieval, tool calls, latency, cost, model behaviour, and quality trends are measured appropriately. ### Deliverables - AI feasibility and risk assessment - Architecture and model strategy - Production AI application, workflow, or API - Retrieval and data pipelines - Evaluation datasets and quality framework - Guardrails, approvals, tracing, and audit controls - Deployment, monitoring, governance, and operating documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded engineering:** Specialist engineers working inside an existing product, technology, or operations team. - **Managed evolution:** Ongoing maintenance, reliability, security, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **How do you decide whether AI is appropriate?** We evaluate the task, available evidence, error tolerance, workflow impact, cost, latency, privacy, and measurable advantage over deterministic software. - **Can sensitive AI actions require approval?** Yes. We implement permissions, policy checks, approval gates, audit trails, fallbacks, and escalation paths based on action risk. - **Can Rokad use private or self-hosted models?** Yes. Model strategy can include managed providers, open-weight models, private infrastructure, or hybrid routing based on security, performance, cost, and operational constraints. - **How is AI quality measured after launch?** We combine offline evaluation, production telemetry, user feedback, sampled review, failure analysis, and controlled release gates. - **Can you integrate AI into an existing application?** Yes. We can add AI through APIs, background workflows, embedded interfaces, data pipelines, tool integrations, and governed automation without rebuilding the entire product. --- ## [Service specialisation] AI agent development Canonical URL: https://rokad.co/en/services/ai-development/ai-agents > Rokad builds AI agents that reason over context, use approved tools, coordinate workflows, and operate within explicit permissions, policies, and human controls. Useful agents must do more than generate text. Rokad engineers agent systems with task boundaries, tool contracts, orchestration, state, retrieval, permissions, approval gates, evaluation, tracing, recovery, and operator oversight for dependable work inside real products and operations. ### Designed for - **Organisations automating knowledge-heavy workflows:** Use agents to gather context, analyse, draft, recommend, route, and execute approved steps across existing systems. - **Software companies adding agent capabilities:** Embed controlled tool use, multi-step work, memory, and human collaboration inside a product. - **Teams replacing brittle prompt automations:** Introduce explicit state, tools, policies, evaluation, observability, and recovery around AI-driven workflows. ### Challenges - **The agent appears capable but is not dependable:** Unbounded prompts, inconsistent context, hidden state, and weak tool contracts create unpredictable behaviour. - **Actions carry operational or financial risk:** The system needs permissions, policy evaluation, approval, audit, idempotency, and safe recovery before side effects. - **Failures are difficult to diagnose:** Teams cannot inspect decisions, retrieval, tool calls, model behaviour, cost, latency, or workflow state. ### Capabilities - Single-agent and multi-agent workflow architecture - Tool schemas, connectors, API actions, and controlled execution - State, plans, memory, retrieval, context, and task decomposition - Permissions, policy checks, approvals, budgets, and action limits - Human review, escalation, exception, retry, and recovery workflows - Evaluation, simulation, tracing, audit, cost, and performance controls - Product interfaces, operator consoles, deployment, and managed operation ### Solution components - **Agent runtime:** Task state, planning, context, model routing, tool selection, execution, observation, and completion behaviour. - **Tool and policy layer:** Typed actions, permissions, preconditions, side-effect controls, approval, budgets, and audit evidence. - **Knowledge and memory:** Retrieval, working context, durable state, user preferences, organisational knowledge, and retention rules. - **Operations and evaluation:** Traces, datasets, simulations, quality metrics, failures, costs, latency, versions, and operator intervention. ### Use cases - **Research and analysis agent:** Collect governed evidence, compare sources, synthesise findings, identify uncertainty, and prepare reviewable outputs. - **Customer operations agent:** Interpret requests, gather account context, recommend or execute approved actions, and escalate exceptions. - **Engineering and operations agent:** Inspect systems, prepare changes, run approved diagnostics, coordinate tools, and maintain an auditable work record. - **Back-office workflow agent:** Process documents, validate data, update systems, create drafts, route approvals, and monitor completion. ### Architecture and integration - **Bounded autonomy:** Define what the agent may decide, what requires deterministic validation, and what must remain under human authority. - **Tool contracts:** Use explicit schemas, permissions, preconditions, outputs, error semantics, idempotency, and compensating actions. - **Durable execution:** Persist state and events so long-running work can pause, resume, retry, escalate, and survive infrastructure failure. ### Quality and control - **Measured behaviour:** Representative evaluation data, quality criteria, failure modes, and release thresholds are defined before expanding production use. - **Controlled actions:** Permissions, policy checks, approval gates, audit trails, fallbacks, and escalation paths govern consequential AI behaviour. - **Observable operation:** Inputs, outputs, retrieval, tool calls, latency, cost, model versions, and quality trends are monitored appropriately. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - Agent feasibility, task, risk, and control assessment - Agent, tool, state, knowledge, and policy architecture - Production agent runtime, interfaces, and integrations - Permissions, approvals, budgets, audit, and recovery controls - Evaluation datasets, simulations, quality thresholds, and traces - Deployment, monitoring, operator, and governance documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **How much autonomy should an AI agent have?** Autonomy should follow action risk, reversibility, evidence quality, user expectation, and organisational policy. We separate low-risk assistance, reviewable recommendations, approved actions, and tightly bounded autonomous execution. - **Can agents use our existing software and APIs?** Yes. We expose approved capabilities as typed tools with authentication, permissions, validation, limits, audit, and failure handling rather than giving the model unrestricted system access. - **How do you prevent agents from taking unsafe actions?** Controls can include tool allowlists, scoped credentials, policy checks, approval gates, amount and frequency limits, deterministic validation, sandboxing, idempotency, audit, and escalation. - **Can a human review or take over a task?** Yes. Workflows can pause for approval, request missing information, surface evidence, transfer state to an operator, and resume after a decision. - **How are agent improvements tested?** We use representative tasks, simulations, regression datasets, tool-call assertions, policy tests, human review, production sampling, and controlled model or prompt releases. --- ## [Service specialisation] Generative AI development Canonical URL: https://rokad.co/en/services/ai-development/generative-ai > Rokad develops generative AI applications and product features with model strategy, grounding, evaluation, controls, interfaces, and production operations. Generative AI becomes valuable when it is designed around a defined user task, evidence, quality standard, workflow, and operating cost. Rokad builds generation, transformation, extraction, conversation, voice, document, image, code, and multimodal capabilities within reliable software systems. ### Designed for - **Product teams adding AI-native experiences:** Create differentiated generation, assistance, conversation, transformation, and multimodal workflows inside an existing or new product. - **Organisations improving knowledge work:** Support drafting, summarisation, extraction, review, translation, classification, and evidence-based analysis. - **Teams moving beyond prompt prototypes:** Introduce data, workflow, evaluation, security, cost, latency, fallback, and operational control. ### Challenges - **Outputs are inconsistent or difficult to trust:** The system lacks task definition, grounding, output structure, validation, examples, evaluation, and user feedback. - **Model cost and latency undermine the product:** Every request uses the same context and model without routing, caching, batching, limits, or economic controls. - **Sensitive data crosses unclear boundaries:** Provider, retention, logging, access, prompt injection, content, and output risks have not been designed explicitly. ### Capabilities - Conversational, drafting, summarisation, extraction, and transformation applications - Document, voice, image, video, code, and multimodal workflows - Prompt, context, schema, tool, and structured-output engineering - Model selection, routing, fallback, caching, batching, and cost control - Grounding, retrieval, validation, moderation, and human review - Evaluation datasets, quality metrics, tracing, feedback, and release controls - Product interfaces, APIs, integrations, deployment, and managed operation ### Solution components - **User workflow:** The input, context, interaction, review, editing, approval, export, and downstream action around the generated result. - **Generation pipeline:** Model, instructions, examples, context, retrieval, tools, output schema, validation, retry, and fallback. - **Safety and governance:** Data access, provider controls, content policy, injection defence, moderation, review, logging, and retention. - **Quality and economics:** Evaluation, user feedback, latency, token usage, model routing, caching, cost allocation, and version comparison. ### Use cases - **Document intelligence:** Extract, classify, summarise, compare, draft, and route information from contracts, reports, forms, and records. - **Product copilot:** Help users understand data, complete tasks, generate work, and navigate application capabilities in context. - **Voice and conversational application:** Combine speech, language, tools, retrieval, memory, and escalation for a defined service or workflow. - **Content production system:** Generate, transform, localise, review, approve, and publish content under brand, evidence, and workflow controls. ### Architecture and integration - **Model portfolio:** Route tasks across managed, open-weight, specialised, local, or fallback models based on quality, privacy, latency, and cost. - **Context boundary:** Assemble only the authorised, relevant, current evidence required for the task and defend the instruction hierarchy. - **Structured result path:** Use schemas, validation, deterministic rules, review, and downstream contracts where generated output affects systems or decisions. ### Quality and control - **Measured behaviour:** Representative evaluation data, quality criteria, failure modes, and release thresholds are defined before expanding production use. - **Controlled actions:** Permissions, policy checks, approval gates, audit trails, fallbacks, and escalation paths govern consequential AI behaviour. - **Observable operation:** Inputs, outputs, retrieval, tool calls, latency, cost, model versions, and quality trends are monitored appropriately. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - Generative AI use-case, data, risk, and model assessment - Workflow, context, model, evaluation, and control architecture - Production application, API, interface, and integrations - Prompts, schemas, retrieval, validation, moderation, and fallbacks - Evaluation datasets, quality thresholds, cost, and latency controls - Deployment, monitoring, governance, and operating documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Which model provider should we use?** We compare quality, modality, context, latency, cost, privacy, regional availability, tooling, reliability, and portability. The system can route across more than one model where justified. - **Can generative AI produce structured data?** Yes. We use constrained schemas, extraction patterns, validation, deterministic checks, confidence or review rules, and retries before downstream use. - **How do you reduce hallucinations?** We narrow the task, ground outputs in authorised evidence, require citations where appropriate, use structured outputs, validate claims, add review, evaluate failures, and avoid using generation where deterministic logic is superior. - **Can sensitive data remain private?** Yes. The design can use provider privacy controls, regional services, private networking, open-weight models, self-hosting, access controls, minimisation, redaction, and explicit retention policies. --- ## [Service specialisation] RAG and enterprise knowledge systems Canonical URL: https://rokad.co/en/services/ai-development/rag > Rokad develops retrieval-augmented generation and enterprise knowledge systems that connect AI to governed, current, source-verifiable information. A dependable knowledge system requires more than embeddings. Rokad designs ingestion, parsing, metadata, permissions, indexing, retrieval, reranking, context assembly, generation, citations, evaluation, feedback, and content-lifecycle operations around the organisation's information. ### Designed for - **Organisations with fragmented private knowledge:** Make policies, research, documentation, records, and expertise searchable and usable through governed interfaces. - **Products requiring source-grounded AI:** Add answers, analysis, assistance, and generation that can be traced back to authorised evidence. - **Teams with an underperforming RAG prototype:** Improve ingestion, retrieval, metadata, permissions, context, evaluation, observability, and content operations. ### Challenges - **Relevant information is difficult to find:** Knowledge is distributed across files, systems, formats, teams, versions, and access boundaries. - **Answers sound plausible but lack evidence:** Retrieval quality, source authority, freshness, citations, and refusal behaviour are not measured or controlled. - **The index does not respect governance:** Content access, deletion, retention, versions, source permissions, and audit requirements are disconnected from retrieval. ### Capabilities - Source discovery, connectors, ingestion, parsing, OCR coordination, and normalisation - Chunking, metadata, taxonomy, entities, version, freshness, and authority modelling - Keyword, vector, hybrid, graph, filtered, and reranked retrieval - Permission-aware search and context assembly - Grounded generation, citations, refusal, and evidence interfaces - Retrieval and answer evaluation, feedback, traces, and failure analysis - Content lifecycle, reindexing, deletion, monitoring, and managed operation ### Solution components - **Knowledge ingestion:** Connectors, extraction, parsing, structure, metadata, versioning, deduplication, quality checks, and update detection. - **Retrieval system:** Queries, filters, hybrid search, semantic matching, reranking, authority, freshness, permissions, and context selection. - **Grounded experience:** Answers, citations, excerpts, source navigation, uncertainty, clarification, feedback, and task-specific interfaces. - **Knowledge operations:** Source health, indexing, access, retention, evaluation, failure review, content gaps, and governance reporting. ### Use cases - **Enterprise knowledge assistant:** Answer employee questions across policies, procedures, documentation, research, and approved internal sources. - **Customer support knowledge system:** Ground support responses and agent assistance in current product, account, policy, and troubleshooting information. - **Research and evidence platform:** Find, compare, synthesise, and cite information across reports, papers, records, and structured datasets. - **Document review workflow:** Retrieve clauses, requirements, evidence, differences, precedents, and related records for a defined review task. ### Architecture and integration - **Authority and freshness:** Model which sources are current, approved, superseded, jurisdiction-specific, or authoritative for each task. - **Permission-aware retrieval:** Carry source access rules through indexing, query, retrieval, context, citation, cache, and audit layers. - **Evaluation decomposition:** Measure ingestion, retrieval relevance, context sufficiency, answer grounding, citation correctness, and end-task usefulness separately. ### Quality and control - **Measured behaviour:** Representative evaluation data, quality criteria, failure modes, and release thresholds are defined before expanding production use. - **Controlled actions:** Permissions, policy checks, approval gates, audit trails, fallbacks, and escalation paths govern consequential AI behaviour. - **Observable operation:** Inputs, outputs, retrieval, tool calls, latency, cost, model versions, and quality trends are monitored appropriately. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - Knowledge-source, access, task, and risk assessment - Ingestion, metadata, index, retrieval, and permission architecture - Production search, RAG, API, and user interfaces - Source connectors, parsing, indexing, update, and deletion workflows - Retrieval and answer evaluation datasets and dashboards - Governance, monitoring, content-operation, and handover documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Why does a basic RAG prototype often perform poorly?** Common causes include weak parsing, arbitrary chunks, missing metadata, poor queries, unsuitable embeddings, no reranking, stale sources, permission gaps, excessive context, and absent evaluation. - **Can the system cite its sources?** Yes. We preserve source identity and location through ingestion, retrieval, context, and output so users can inspect the evidence behind an answer. - **Can access permissions be respected?** Yes. Permission-aware retrieval can enforce user, group, tenant, document, field, and source rules, provided the source systems expose reliable access information. - **How is RAG quality evaluated?** We test ingestion quality, retrieval relevance, ranking, context sufficiency, grounding, citation correctness, refusal, latency, cost, and usefulness on representative questions and tasks. - **Can the index stay current as documents change?** Yes. We design incremental updates, version handling, deletion, reindexing, connector health, source timestamps, and stale-content monitoring. --- ## [Service specialisation] AI integration services Canonical URL: https://rokad.co/en/services/ai-development/ai-integration > Rokad integrates AI into existing software and business workflows through secure APIs, interfaces, data pipelines, evaluations, and operating controls. AI integration should improve a specific user or operational outcome without destabilising the surrounding system. Rokad connects models, retrieval, agents, extraction, generation, classification, recommendation, and automation to existing products, data, applications, and approval workflows. ### Designed for - **Product teams adding AI without rebuilding the platform:** Introduce focused capabilities through modular services, APIs, background workflows, and embedded interfaces. - **Operations teams connecting AI to existing tools:** Use AI across CRM, support, documents, communication, knowledge, finance, or internal applications with human control. - **Organisations consolidating AI experiments:** Replace isolated pilots with shared model access, governance, observability, evaluation, and reusable platform components. ### Challenges - **The AI demo is disconnected from the workflow:** Users must manually move context and outputs between systems, reducing adoption and increasing error. - **Existing architecture was not designed for AI:** Long-running work, probabilistic outputs, provider limits, evaluation, context, and feedback require new system patterns. - **Multiple teams use models without common controls:** Credentials, data, prompts, providers, cost, quality, logging, and release behaviour are inconsistent. ### Capabilities - AI opportunity and workflow integration assessment - Model-provider, open-weight, private, and hybrid integration - Generation, extraction, classification, recommendation, search, and agent APIs - Product UI, background jobs, events, queues, and human-review workflows - CRM, support, document, communication, data, and enterprise-system integration - Shared model gateway, routing, policy, cost, logging, and evaluation services - Security, observability, rollout, fallback, and managed operation ### Solution components - **Workflow insertion point:** Define where AI receives context, supports a decision, creates an output, requests review, or triggers an approved action. - **AI service boundary:** Provide stable contracts for model access, retrieval, prompts, tools, validation, logging, cost, and provider change. - **Human and deterministic controls:** Keep policy, permissions, business invariants, approvals, validation, and high-risk decisions outside unconstrained generation. - **Adoption and operation:** Measure quality, user behaviour, time saved, exceptions, cost, latency, failures, and workflow impact after rollout. ### Use cases - **AI inside a SaaS product:** Add assistance, extraction, generation, search, recommendation, or automation to an existing customer workflow. - **Document processing integration:** Receive files, extract and validate data, request review, update systems, and preserve evidence and audit history. - **Customer-service augmentation:** Ground answers, summarise interactions, recommend actions, draft responses, and automate approved service steps. - **Enterprise AI gateway:** Provide reusable provider access, routing, policy, telemetry, cost, and evaluation capabilities across teams. ### Architecture and integration - **Loose coupling:** Expose AI through stable service contracts so models, providers, prompts, and retrieval can evolve without rewriting the product. - **Asynchronous execution:** Use queues, durable workflows, callbacks, status, cancellation, and retries for long-running or rate-limited tasks. - **Progressive rollout:** Introduce shadowing, assistance, optional use, approval, limited cohorts, and monitored expansion before deeper automation. ### Quality and control - **Measured behaviour:** Representative evaluation data, quality criteria, failure modes, and release thresholds are defined before expanding production use. - **Controlled actions:** Permissions, policy checks, approval gates, audit trails, fallbacks, and escalation paths govern consequential AI behaviour. - **Observable operation:** Inputs, outputs, retrieval, tool calls, latency, cost, model versions, and quality trends are monitored appropriately. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - AI integration opportunity, workflow, and risk assessment - Model, service, data, interface, and control architecture - Production AI service, API, product interface, and system integrations - Validation, approval, fallback, security, and audit controls - Evaluation, telemetry, cost, latency, and rollout dashboards - Technical, operator, governance, and handover documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Can AI be added without rebuilding our application?** Usually yes. We can introduce modular AI services, APIs, background workflows, event handlers, embedded interfaces, and review queues around the existing product architecture. - **Can we change model providers later?** Yes. We can separate provider-specific behaviour behind a model or AI-service boundary, although capabilities and output behaviour still require evaluation when providers change. - **How do you roll out AI safely to existing users?** We can use internal testing, shadow execution, optional assistance, review-required outputs, limited cohorts, feature flags, quality thresholds, monitoring, and rollback. - **Can one integration support several AI use cases?** Yes. Shared model access, retrieval, policy, telemetry, evaluation, and cost components can support multiple product and workflow capabilities while keeping task-specific logic separate. --- ## [Platform service] OpenAI integration and development services Canonical URL: https://rokad.co/en/services/ai-development/ai-integration/openai Platform: OpenAI > Rokad builds production AI applications and integrations with OpenAI APIs across agents, tools, retrieval, structured outputs, multimodal workflows, evaluations, and observability. OpenAI APIs can support assistants, agents, extraction, generation, search, multimodal interfaces, and tool-enabled workflows. Rokad engineers the surrounding application, data, permissions, evaluation, fallback, cost, latency, audit, and operational controls required for dependable business use. ### Designed for - **Product teams adding AI-native capabilities:** Integrate generation, extraction, classification, conversation, search, recommendations, multimodal input, and agent workflows into software products. - **Enterprises connecting AI to private knowledge and tools:** Build governed retrieval, file workflows, authorised actions, approval gates, audit, and identity-aware applications. - **Teams moving prototypes into production:** Introduce evaluations, structured outputs, observability, provider abstractions, cost controls, security, and release discipline. ### Implementation risks - **A prompt demo lacks an application contract:** Inputs, outputs, schemas, tools, data, failure, confidence, user experience, and escalation are not defined. - **Tool-enabled agents can create unintended changes:** Permissions, approval, idempotency, validation, audit, rate limits, and recovery are missing around application actions. - **Model updates and variability affect production quality:** Representative evals, version tracking, regression thresholds, fallback, and release controls are not established. ### Platform capabilities - OpenAI API strategy, task design, model selection, architecture, and feasibility - Responses API integration, streaming, conversation state, structured outputs, and function tools - Agent workflows, tool orchestration, approvals, application actions, and multi-step execution - File search, vector stores, embeddings, retrieval, document processing, and private knowledge - Text, image, audio, file, and multimodal product experiences - Prompt, tool, retrieval, safety, latency, cost, and agent evaluation systems - Tracing, monitoring, quotas, caching, fallbacks, provider abstraction, security, and managed operation ### Implementation system - **AI application contract:** Tasks, inputs, context, outputs, schemas, tools, permissions, uncertainty, user control, and failure behaviour. - **OpenAI integration layer:** Responses, tools, streaming, structured output, files, retrieval, model routing, rate limits, and state. - **Knowledge and action system:** Documents, embeddings, retrieval, citations, functions, APIs, approvals, audit, idempotency, and recovery. - **Evaluation and operation:** Datasets, graders, regression, traces, latency, cost, quality, safety, versions, incidents, and release gates. ### Use cases - **AI product assistant:** Provide contextual conversation, product actions, account workflows, recommendations, and escalation inside an application. - **Document intelligence:** Extract structured information, classify files, summarise content, validate fields, route review, and update systems. - **Enterprise knowledge agent:** Retrieve governed private information, cite sources, synthesise answers, and use authorised tools under policy. - **AI workflow automation:** Analyse requests, draft outputs, call business APIs, request approval, record evidence, and recover from failure. ### Architecture - **Structured output at system boundaries:** Use explicit schemas and validation when model output drives databases, APIs, workflows, decisions, or user interfaces. - **Tools expose narrow authorised capabilities:** Define scoped functions with validated arguments, identity context, policy, approval, idempotency, and audit. - **Evaluation controls model change:** Run representative tests across prompts, tools, retrieval, models, latency, cost, and safety before production release. ### Quality and governance - **Evaluated behaviour:** Representative datasets, task criteria, failure modes, model comparisons, and release thresholds are defined before production expansion. - **Governed model access:** Identity, data boundaries, tool permissions, moderation, approvals, audit, retention, and provider controls match the use case. - **Provider-aware operation:** Models, prompts, tools, latency, cost, quotas, versions, fallbacks, telemetry, and migration risk are monitored explicitly. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - OpenAI use-case, data, model, security, cost, and risk assessment - Application, agent, tool, retrieval, evaluation, and operating architecture - Production OpenAI API integrations, agents, structured workflows, and user experiences - Knowledge, file, retrieval, tool, approval, audit, and application integrations - Evaluation datasets, regression tests, tracing, monitoring, cost, and release controls - Developer, product, operator, governance, support, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad integrate OpenAI into an existing product?** Yes. We can add API-backed features, background workflows, agents, retrieval, structured extraction, multimodal experiences, and governed actions without rebuilding the entire product. - **Can OpenAI use our private documents?** Yes, through an architecture that defines data selection, upload or retrieval, permissions, indexing, retention, citations, audit, and deletion according to requirements. - **How is OpenAI output quality measured?** We create representative datasets and evaluate task success, structure, retrieval, tool use, safety, latency, cost, and business-specific failure modes. - **Can Rokad support more than one AI provider?** Yes. We can design provider abstractions, routing, fallbacks, evaluation, data boundaries, and migration paths where resilience or model choice justifies it. --- ## [Platform service] Anthropic Claude integration services Canonical URL: https://rokad.co/en/services/ai-development/ai-integration/anthropic-claude Platform: Anthropic Claude > Rokad builds production applications and agent workflows with Anthropic Claude across tool use, long-context analysis, retrieval, MCP, structured outputs, and evaluation. Claude can support analysis, coding, document-intensive work, agent workflows, and tool-enabled applications. Rokad defines task boundaries, context strategy, tool permissions, MCP integration, prompt and response contracts, human control, evaluation, observability, cost, and provider lifecycle. ### Designed for - **Teams building document and reasoning applications:** Use Claude for synthesis, analysis, extraction, drafting, coding, research, and long-context workflows with measurable criteria. - **Enterprises developing tool-enabled agents:** Connect Claude to authorised systems through functions or MCP with policy, approval, audit, and recovery. - **Products adopting multiple model providers:** Evaluate Claude against tasks, route work appropriately, and maintain abstractions, fallbacks, and migration controls. ### Implementation risks - **Large context is used without information architecture:** Documents, instructions, retrieved evidence, tool results, and conversation state compete for attention and increase cost. - **Agent tools expose excessive authority:** Broad APIs and MCP servers allow actions without scoped permissions, validation, approval, or transaction recovery. - **Qualitative preference replaces evaluation:** Teams select models from a few demonstrations rather than representative tasks, failure modes, latency, and cost. ### Platform capabilities - Claude API task design, model evaluation, architecture, and production integration - Messages API, streaming, tool use, structured application workflows, and conversation state - Long-context document analysis, synthesis, extraction, comparison, drafting, and review - MCP client and server integration, authorised tools, resources, identity, and policy - Retrieval, citations, knowledge systems, prompt caching, context composition, and data controls - Agent workflows, approval gates, human review, audit, fallback, and recovery - Evaluation, tracing, latency, cost, quotas, versions, provider routing, and managed operation ### Implementation system - **Claude task contract:** Instructions, context, evidence, outputs, tools, uncertainty, constraints, review, escalation, and success criteria. - **Context architecture:** System instructions, conversation, documents, retrieval, cached context, tool results, compression, and provenance. - **Tool and MCP layer:** Functions, servers, resources, schemas, authentication, permissions, approvals, validation, audit, and recovery. - **Production evaluation:** Datasets, graders, tool trajectories, document fidelity, latency, cost, safety, regressions, and release decisions. ### Use cases - **Document and contract analysis:** Compare, extract, summarise, identify issues, cite evidence, route review, and produce structured outputs. - **Research and knowledge assistant:** Combine governed retrieval, long-context synthesis, source handling, structured findings, and human verification. - **Developer and code workflows:** Support code understanding, planning, review, transformation, testing, documentation, and controlled tool use. - **Enterprise MCP agent:** Expose approved data and actions through MCP with user identity, policy, audit, approval, and operational boundaries. ### Architecture - **Context is curated, not accumulated:** Select relevant instructions and evidence, preserve provenance, summarise stale state, and avoid sending unnecessary data. - **MCP servers are trust boundaries:** Authenticate users and services, expose narrow capabilities, validate arguments, limit data, log actions, and manage versions. - **Agent trajectories are evaluated:** Measure tool choice, sequence, parameters, evidence, final output, cost, latency, and recovery—not only the final prose. ### Quality and governance - **Evaluated behaviour:** Representative datasets, task criteria, failure modes, model comparisons, and release thresholds are defined before production expansion. - **Governed model access:** Identity, data boundaries, tool permissions, moderation, approvals, audit, retention, and provider controls match the use case. - **Provider-aware operation:** Models, prompts, tools, latency, cost, quotas, versions, fallbacks, telemetry, and migration risk are monitored explicitly. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Claude use-case, context, tool, data, provider, security, and risk assessment - Application, context, MCP, tool, retrieval, evaluation, and operating architecture - Production Claude API applications, agents, document workflows, and integrations - MCP servers or clients, tools, permissions, approvals, audit, and recovery controls - Evaluation datasets, trajectory tests, tracing, monitoring, cost, and release controls - Developer, product, operator, governance, support, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad build MCP integrations for Claude?** Yes. We can design and implement MCP clients or servers with tools, resources, schemas, authentication, identity context, permissions, audit, deployment, and support. - **Can Claude analyse large document collections?** Yes, but collection design may combine direct context, retrieval, chunking, metadata, filtering, citations, cached context, and staged analysis according to scale and task. - **Can Claude call business systems safely?** Yes, when tools are narrowly scoped and surrounded by validation, policy, approvals, idempotency, audit, limits, and recovery appropriate to the action. - **Can Rokad compare Claude with other providers?** Yes. We evaluate representative tasks across quality, tools, context, latency, cost, safety, hosting, data controls, and operating requirements. --- ## [Platform service] Google Gemini integration services Canonical URL: https://rokad.co/en/services/ai-development/ai-integration/google-gemini Platform: Google Gemini > Rokad builds Gemini-powered applications across multimodal understanding, function calling, structured outputs, grounding, agents, Vertex AI, and production evaluation. Gemini supports text, image, audio, video, files, structured output, function calling, and grounded application patterns. Rokad designs the user experience, context, data, tools, model access, Google Cloud integration, evaluation, safety, latency, cost, and production operations. ### Designed for - **Products building multimodal AI experiences:** Analyse and generate across text, images, audio, video, files, live interactions, and structured application state. - **Google Cloud organisations adopting enterprise AI:** Use Vertex AI identity, networking, data, monitoring, evaluation, governance, and application infrastructure. - **Teams requiring grounded and tool-enabled applications:** Combine search or private data with function calls, structured outputs, application actions, and verification. ### Implementation risks - **Multimodal input lacks a consistent task model:** Files, frames, images, audio, text, metadata, timing, quality, and output requirements are not normalised. - **Grounding is treated as guaranteed truth:** Sources, retrieval quality, citations, freshness, conflicting evidence, unsupported claims, and user verification are not controlled. - **Google AI and cloud responsibilities are fragmented:** API access, projects, identities, regions, data, quotas, logging, networking, billing, and operations lack one architecture. ### Platform capabilities - Gemini API and Vertex AI architecture, model evaluation, task design, and integration - Text, image, audio, video, file, document, and multimodal application workflows - Function calling, structured outputs, application actions, schemas, tools, and approvals - Grounding with search or private data, retrieval, citations, verification, and knowledge systems - Agent and live-interaction experiences, streaming, session state, and user interfaces - Google Cloud identity, projects, networking, data, storage, logging, monitoring, and deployment - Evaluation, tracing, safety, latency, cost, quotas, versions, fallbacks, and managed operation ### Implementation system - **Multimodal input pipeline:** Capture, upload, transform, segment, metadata, quality, privacy, storage, context, and task-specific representation. - **Gemini application layer:** Models, prompts, structured output, function calls, streaming, sessions, grounding, and application contracts. - **Google Cloud foundation:** Projects, identity, regions, networking, storage, data, APIs, quotas, monitoring, billing, and deployment. - **Evaluation and governance:** Datasets, multimodal quality, groundedness, tool use, safety, latency, cost, audit, and release controls. ### Use cases - **Multimodal document and media analysis:** Understand text, images, tables, audio, video, and metadata, then produce structured findings and review workflows. - **Grounded customer or employee assistant:** Combine Google or private search with source-aware responses, application context, tools, and escalation. - **Visual inspection and field workflows:** Analyse images or video, collect context, classify issues, produce structured records, and route human validation. - **Gemini agent on Google Cloud:** Use authorised functions, enterprise data, cloud services, identity, monitoring, evaluation, and application controls. ### Architecture - **Multimodal evidence is normalised:** Define resolution, duration, sampling, file formats, metadata, privacy, retention, and output schemas for each input type. - **Grounded claims remain inspectable:** Preserve source references, retrieval context, freshness, confidence, unsupported cases, and user access to evidence. - **Google Cloud identity surrounds actions:** Use scoped service identities, project boundaries, secrets, policy, audit, network controls, and approvals for tools and data. ### Quality and governance - **Evaluated behaviour:** Representative datasets, task criteria, failure modes, model comparisons, and release thresholds are defined before production expansion. - **Governed model access:** Identity, data boundaries, tool permissions, moderation, approvals, audit, retention, and provider controls match the use case. - **Provider-aware operation:** Models, prompts, tools, latency, cost, quotas, versions, fallbacks, telemetry, and migration risk are monitored explicitly. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Gemini use-case, modality, grounding, data, cloud, security, and risk assessment - Multimodal, application, tool, grounding, Vertex AI, evaluation, and operating architecture - Production Gemini API or Vertex AI applications, agents, and multimodal workflows - Functions, structured outputs, search, retrieval, data, Google Cloud, and application integrations - Evaluation datasets, groundedness tests, tracing, monitoring, safety, cost, and release controls - Developer, product, cloud, operator, governance, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Gemini process images, audio, video, and documents?** Yes, depending on the selected model and API. We design file preparation, segmentation, metadata, context, structured outputs, quality checks, and user review around the task. - **Should we use the Gemini API or Vertex AI?** The choice depends on identity, cloud governance, networking, regions, enterprise controls, data, operations, integrations, and product requirements. - **Can Gemini call functions and APIs?** Yes. We define tool schemas, validation, permissions, identity, approvals, idempotency, audit, timeouts, and recovery around application actions. - **Can Rokad evaluate Gemini against other models?** Yes. We compare representative tasks across multimodal quality, grounding, tool use, latency, cost, safety, context, and operational fit. --- ## [Platform service] Microsoft Foundry development services Canonical URL: https://rokad.co/en/services/ai-development/ai-integration/microsoft-foundry Platform: Microsoft Foundry > Rokad develops enterprise AI applications with Microsoft Foundry across models, agents, tools, evaluations, tracing, monitoring, security, data, and Azure integration. Microsoft Foundry provides a unified Azure environment for enterprise AI application development, models, agents, tools, tracing, monitoring, and evaluations. Rokad designs the surrounding application, identity, network, data, retrieval, tool, governance, deployment, evaluation, and operating architecture. ### Designed for - **Azure enterprises building governed AI applications:** Use existing identity, networking, security, data, monitoring, and cloud operations around models and agents. - **Teams comparing and operating several models:** Evaluate model catalogue options, route workloads, track versions, and control quality, latency, cost, and data requirements. - **Organisations deploying enterprise agents:** Connect agents to tools and data with identities, permissions, evaluation, tracing, approval, and audit. ### Implementation risks - **AI projects bypass established Azure governance:** Projects, subscriptions, identity, network, data, regions, secrets, logging, cost, and support are created outside normal controls. - **Model choice is not tied to task evidence:** Teams select a model from reputation or demos without representative evaluation, routing, fallback, or lifecycle planning. - **Agent tools cross enterprise trust boundaries:** Business applications, databases, files, actions, and credentials are exposed without scoped identity and policy. ### Platform capabilities - Microsoft Foundry architecture, project, model, agent, data, network, security, and operational assessment - Model catalogue evaluation, deployment, routing, versioning, quotas, latency, cost, and fallback - Foundry Agent Service, tools, knowledge, state, actions, approvals, and application integration - Prompt, flow, retrieval, search, data, files, Azure services, and enterprise knowledge integration - Azure identity, managed identities, network, private access, Key Vault, policy, logging, and compliance controls - Tracing, monitoring, evaluations, safety, red-teaming support, dashboards, and release gates - Application deployment, CI/CD, environments, observability, support, governance, and managed operation ### Implementation system - **Azure AI foundation:** Subscriptions, projects, identity, network, regions, secrets, storage, data, APIs, policy, logging, and cost. - **Model and agent layer:** Catalogue, deployments, prompts, agents, tools, knowledge, state, routing, quotas, versions, and fallback. - **Enterprise integration:** Azure services, search, data, applications, APIs, files, identities, approvals, audit, and business workflows. - **AI operations:** Tracing, monitoring, evaluations, safety, incidents, latency, cost, quality, releases, governance, and support. ### Use cases - **Enterprise knowledge agent:** Connect governed organisational information, search, files, identity, citations, tools, and escalation on Azure. - **AI application platform:** Provide reusable model, prompt, agent, evaluation, tracing, deployment, security, and integration capabilities to teams. - **Business workflow agent:** Analyse requests, retrieve evidence, use authorised tools, request approval, update systems, and preserve audit records. - **Model evaluation and routing:** Compare models against task datasets and route workloads by quality, latency, cost, region, and control requirements. ### Architecture - **Foundry projects align with ownership boundaries:** Separate environments, products, data, identities, budgets, teams, and risk while maintaining shared standards and observability. - **Managed identity replaces embedded secrets:** Use scoped Azure identities and service connections for data, tools, storage, search, deployment, and monitoring where supported. - **Evaluations govern model and agent release:** Measure task quality, safety, groundedness, tool trajectories, latency, cost, and regressions before promotion. ### Quality and governance - **Evaluated behaviour:** Representative datasets, task criteria, failure modes, model comparisons, and release thresholds are defined before production expansion. - **Governed model access:** Identity, data boundaries, tool permissions, moderation, approvals, audit, retention, and provider controls match the use case. - **Provider-aware operation:** Models, prompts, tools, latency, cost, quotas, versions, fallbacks, telemetry, and migration risk are monitored explicitly. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Microsoft Foundry model, agent, data, Azure, security, governance, and risk assessment - Project, identity, network, model, agent, tool, evaluation, and operating architecture - Production Foundry applications, agent services, model integrations, and enterprise workflows - Search, retrieval, data, Azure service, tool, approval, identity, and audit integrations - Tracing, monitoring, evaluation, safety, cost, deployment, and release controls - Developer, cloud, security, operator, governance, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **What is Microsoft Foundry used for?** It provides Azure services for developing and operating enterprise AI applications with models, agents, tools, tracing, monitoring, evaluations, and governance capabilities. - **Can Foundry connect to private enterprise data?** Yes. We design identity, network, search, storage, database, file, retrieval, permission, logging, retention, and citation controls around the data source. - **Can Rokad build agents in Microsoft Foundry?** Yes. We can define tools, knowledge, instructions, state, identity, approvals, evaluation, tracing, application integration, and production operation. - **Can Rokad integrate Foundry with existing Azure systems?** Yes. We can integrate identity, search, storage, data platforms, APIs, functions, applications, monitoring, networking, security, and CI/CD. --- ## [Platform service] Amazon Bedrock development services Canonical URL: https://rokad.co/en/services/ai-development/ai-integration/amazon-bedrock Platform: Amazon Bedrock > Rokad develops enterprise generative AI applications on Amazon Bedrock across foundation models, agents, knowledge bases, guardrails, evaluations, and AWS integration. Amazon Bedrock provides managed access to foundation models and services for agents, knowledge bases, guardrails, and evaluation within AWS. Rokad designs account, region, identity, data, model, retrieval, tool, security, application, observability, and cost architecture around the business task. ### Designed for - **AWS organisations adopting generative AI:** Use existing cloud identity, networking, storage, data, monitoring, security, and operational practices around AI workloads. - **Teams requiring managed multi-model access:** Evaluate and route foundation models while keeping application, data, permissions, evaluation, and operations consistent. - **Enterprises building knowledge and agent systems:** Combine Knowledge Bases, agents, guardrails, AWS services, business APIs, approvals, and audit. ### Implementation risks - **Model choice is separated from application evaluation:** Teams enable several models without task datasets, routing criteria, version controls, cost models, or fallback behaviour. - **Knowledge Bases are treated as automatic accuracy:** Chunking, metadata, filters, source quality, retrieval, citations, access, freshness, and evaluation are not engineered. - **AWS permissions become overly broad:** Agents, functions, data, storage, search, secrets, logs, and application services share roles without least-privilege boundaries. ### Platform capabilities - Amazon Bedrock use-case, model, region, account, data, security, cost, and architecture assessment - Foundation model access, inference profiles, routing, evaluation, versioning, quotas, latency, and fallback - Bedrock Agents, action groups, APIs, functions, state, approvals, audit, and application integration - Knowledge Bases, ingestion, chunking, metadata, retrieval, reranking, citations, and RAG evaluation - Guardrails, policy, content controls, sensitive data handling, application safeguards, and human review - IAM, VPC, KMS, S3, Lambda, search, databases, logging, monitoring, and AWS service integration - Deployment, CI/CD, observability, model evaluation, cost, support, governance, and managed operation ### Implementation system - **AWS AI foundation:** Accounts, regions, IAM, network, encryption, storage, data, logging, secrets, quotas, billing, and deployment. - **Model and agent layer:** Models, inference, prompts, agents, action groups, sessions, routing, versions, guardrails, and fallback. - **Knowledge system:** Sources, ingestion, parsing, chunking, metadata, embeddings, retrieval, reranking, citations, access, and freshness. - **Evaluation and operation:** Model and RAG evaluation, traces, logs, quality, safety, latency, cost, incidents, releases, and governance. ### Use cases - **AWS enterprise knowledge assistant:** Use governed documents and data with Knowledge Bases, citations, identity, application context, and escalation. - **Bedrock business agent:** Connect agents to AWS and enterprise tools with action groups, permissions, validation, approvals, and audit. - **Multi-model AI application:** Route tasks across available models using quality, modality, latency, cost, region, and governance criteria. - **Document and workflow intelligence:** Extract, classify, summarise, validate, retrieve, route review, and update business systems on AWS. ### Architecture - **IAM follows every tool and data boundary:** Give agents, functions, applications, ingestion, retrieval, and operations separate scoped roles and audit trails. - **RAG is evaluated as a pipeline:** Measure source quality, parsing, chunks, metadata, retrieval, ranking, citations, response, latency, and cost together. - **Model access remains replaceable:** Keep task contracts, evaluation, prompts, schemas, tools, and application logic sufficiently separated from model-specific behaviour. ### Quality and governance - **Evaluated behaviour:** Representative datasets, task criteria, failure modes, model comparisons, and release thresholds are defined before production expansion. - **Governed model access:** Identity, data boundaries, tool permissions, moderation, approvals, audit, retention, and provider controls match the use case. - **Provider-aware operation:** Models, prompts, tools, latency, cost, quotas, versions, fallbacks, telemetry, and migration risk are monitored explicitly. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Bedrock model, account, region, data, IAM, security, cost, and risk assessment - Model, agent, Knowledge Base, guardrail, AWS integration, evaluation, and operating architecture - Production Bedrock applications, agents, action groups, knowledge systems, and workflows - AWS identity, network, storage, search, data, functions, APIs, logging, and application integrations - Model and RAG evaluations, guardrails, monitoring, latency, cost, deployment, and release controls - Developer, cloud, security, operator, governance, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad help select a model in Amazon Bedrock?** Yes. We evaluate representative tasks across quality, modality, tools, context, latency, cost, region, quotas, data controls, and operational fit. - **Can Bedrock connect to private documents?** Yes. We can implement Knowledge Bases or custom retrieval with source access, ingestion, metadata, chunking, citations, permissions, freshness, and evaluation. - **Can Rokad build Bedrock agents?** Yes. We design action groups, APIs, functions, permissions, state, validation, approvals, guardrails, audit, evaluation, and application integration. - **Can Rokad manage Bedrock applications after launch?** Yes. Managed services can cover models, agents, knowledge ingestion, evaluations, monitoring, security, AWS infrastructure, costs, incidents, and releases. --- ## [Platform service] Hugging Face development services Canonical URL: https://rokad.co/en/services/ai-development/ai-integration/hugging-face Platform: Hugging Face > Rokad develops AI systems with Hugging Face across model discovery, evaluation, fine-tuning, datasets, inference endpoints, custom deployment, applications, and lifecycle operations. Hugging Face provides an ecosystem for discovering, evaluating, adapting, deploying, and demonstrating open and proprietary models. Rokad helps teams select models responsibly, validate licences and capabilities, prepare data, fine-tune where justified, deploy inference, build applications, and establish security, observability, cost, and model lifecycle controls. ### Designed for - **Teams evaluating open and specialised models:** Compare models for language, vision, audio, embeddings, classification, generation, and domain-specific tasks. - **Organisations requiring private or controlled inference:** Deploy managed endpoints or custom infrastructure with defined network, hardware, scaling, data, and operational controls. - **AI teams adapting models to proprietary tasks:** Prepare datasets, fine-tune or adapt models, evaluate outcomes, package artefacts, and manage reproducibility. ### Implementation risks - **Model popularity replaces fit assessment:** Teams select models without testing task quality, licence, hardware, latency, memory, context, safety, and maintenance. - **Downloaded artefacts lack supply-chain controls:** Repositories, revisions, custom code, files, dependencies, licences, provenance, and security are not reviewed or pinned. - **Fine-tuning begins before the baseline is understood:** Prompting, retrieval, data quality, evaluation, smaller models, and simpler classifiers are not compared first. ### Platform capabilities - Hugging Face Hub model, dataset, Space, licence, revision, security, and suitability assessment - Transformers, sentence-transformers, diffusers, tokenisation, pipelines, embeddings, and application integration - Dataset preparation, cleaning, labelling, versioning, splitting, governance, and evaluation design - Fine-tuning, parameter-efficient adaptation, training, checkpoints, experiment tracking, and reproducibility - Inference Endpoints, dedicated autoscaling deployment, custom containers, GPU infrastructure, and model servers - Spaces, demos, internal applications, APIs, batch jobs, retrieval, and multi-model workflows - Monitoring, quality, drift, latency, throughput, cost, security, versions, rollback, and managed MLOps ### Implementation system - **Model and licence selection:** Task fit, architecture, modalities, context, benchmarks, licence, provenance, dependencies, hardware, and maintenance. - **Data and adaptation pipeline:** Sources, consent, cleaning, labels, splits, augmentation, training, evaluation, checkpoints, and artefact governance. - **Inference platform:** Endpoints, model server, hardware, quantisation, batching, autoscaling, network, authentication, caching, and deployment. - **Model operations:** Registry, revisions, tests, quality, drift, latency, cost, monitoring, incidents, retraining, rollback, and documentation. ### Use cases - **Open-model evaluation programme:** Shortlist and compare language, embedding, vision, audio, or specialised models against representative tasks and constraints. - **Private inference endpoint:** Deploy a selected model with authentication, network control, autoscaling, observability, quotas, cost, and support. - **Domain model adaptation:** Prepare data and fine-tune or adapt a model for classification, extraction, generation, retrieval, or specialised language. - **AI demo to production transition:** Move a Space or notebook into a tested API, application, data pipeline, deployment, monitoring, and model lifecycle. ### Architecture - **Pin model and code revisions:** Record repositories, commits, files, configuration, tokenizer, custom code, dependencies, licence, and evaluation evidence. - **Baseline before adaptation:** Compare prompts, retrieval, rules, smaller models, embeddings, and existing checkpoints before training new weights. - **Inference is workload engineering:** Design hardware, precision, batching, concurrency, memory, context, caching, scaling, latency, throughput, and cost together. ### Quality and governance - **Evaluated behaviour:** Representative datasets, task criteria, failure modes, model comparisons, and release thresholds are defined before production expansion. - **Governed model access:** Identity, data boundaries, tool permissions, moderation, approvals, audit, retention, and provider controls match the use case. - **Provider-aware operation:** Models, prompts, tools, latency, cost, quotas, versions, fallbacks, telemetry, and migration risk are monitored explicitly. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Model, dataset, licence, security, hardware, task, cost, and risk assessment - Data, adaptation, evaluation, inference, application, and MLOps architecture - Production model integration, fine-tuning pipeline, endpoint, API, or application - Datasets, model artefacts, revisions, tests, evaluation reports, and deployment configuration - Monitoring, quality, drift, latency, scaling, cost, security, and rollback controls - Developer, data, ML, infrastructure, governance, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad help select an open model from Hugging Face?** Yes. We evaluate task quality, modality, licence, provenance, model size, hardware, context, safety, latency, cost, ecosystem, and maintenance. - **Can Rokad deploy Hugging Face models privately?** Yes. We can use managed Inference Endpoints or custom cloud, container, Kubernetes, GPU, network, authentication, monitoring, and scaling architectures. - **Do we need to fine-tune a model?** Not always. We compare prompting, retrieval, structured workflows, classifiers, smaller models, and existing checkpoints before recommending adaptation. - **Can Rokad turn a Hugging Face Space into a production product?** Yes. We can extract the model and application logic into a secure, tested, observable, scalable API and product architecture. --- ## [Service specialisation] Machine learning development Canonical URL: https://rokad.co/en/services/ai-development/machine-learning > Rokad develops machine-learning systems from problem and data assessment through modelling, deployment, monitoring, and business workflow integration. Machine learning is effective when the target, data, decision, feedback, and operating environment are well defined. Rokad builds predictive, ranking, recommendation, classification, forecasting, anomaly, and optimisation systems with reproducible training, evaluation, deployment, and monitoring. ### Designed for - **Organisations with repeatable decisions and historical data:** Use patterns in operational, customer, transaction, device, or market data to improve prioritisation and planning. - **Product teams adding predictive capability:** Embed scoring, recommendation, ranking, forecasting, detection, or personalisation into a software product. - **Teams moving models from notebooks to production:** Establish reproducible data, training, evaluation, serving, monitoring, ownership, and release processes. ### Challenges - **The prediction target is poorly defined:** A technically accurate model may not improve the decision, workflow, timing, or economic outcome that matters. - **Training data does not represent production reality:** Leakage, missing labels, bias, changing processes, sparse events, and delayed outcomes undermine model performance. - **A model exists without an operating system:** Serving, feature consistency, monitoring, feedback, retraining, rollback, and human use have not been designed. ### Capabilities - Problem framing, target definition, baseline, and economic evaluation - Data discovery, quality, labelling, feature, and leakage assessment - Classification, regression, ranking, recommendation, forecasting, anomaly, and optimisation models - Experiment tracking, reproducible training, validation, and model comparison - Batch, real-time, edge, or embedded inference integration - Monitoring, drift, performance, fairness, feedback, retraining, and rollback - Product interfaces, decision workflows, APIs, and managed operation ### Solution components - **Decision definition:** Who uses the prediction, when it arrives, which action follows, what errors cost, and how success is measured. - **Data and feature pipeline:** Sources, labels, joins, timing, transformations, quality checks, feature consistency, lineage, and reproducibility. - **Model and serving:** Baselines, algorithms, validation, calibration, inference, performance, scale, versioning, and fallback behaviour. - **Learning operations:** Production outcomes, drift, feedback, thresholds, review, retraining, approval, rollout, and model retirement. ### Use cases - **Forecasting and planning:** Estimate demand, capacity, inventory, workload, revenue, risk, or operational volume with uncertainty and feedback. - **Recommendation and ranking:** Prioritise products, content, actions, leads, cases, or opportunities using behaviour, context, and constraints. - **Risk and anomaly detection:** Identify unusual transactions, device behaviour, quality patterns, operational events, or security signals for review. - **Classification and routing:** Categorise documents, requests, customers, events, or records and direct them into the appropriate workflow. ### Architecture and integration - **Training-serving consistency:** Use aligned feature definitions, timestamps, transformations, schemas, and validation across historical training and live inference. - **Baseline and fallback:** Compare models against simple rules and preserve deterministic or previous-model behaviour when confidence or system health is insufficient. - **Feedback and delay:** Account for when true outcomes arrive, how user actions affect labels, and how model influence changes future data. ### Quality and control - **Measured behaviour:** Representative evaluation data, quality criteria, failure modes, and release thresholds are defined before expanding production use. - **Controlled actions:** Permissions, policy checks, approval gates, audit trails, fallbacks, and escalation paths govern consequential AI behaviour. - **Observable operation:** Inputs, outputs, retrieval, tool calls, latency, cost, model versions, and quality trends are monitored appropriately. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - ML feasibility, target, data, baseline, and risk assessment - Data, feature, training, validation, and inference architecture - Reproducible model training and experiment pipeline - Production batch, API, streaming, edge, or embedded inference - Evaluation, drift, quality, feedback, and release controls - Model card, technical, governance, and operating documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **How do we know whether we have enough data?** We assess sample volume, target frequency, label quality, time coverage, feature availability, leakage, representativeness, and the performance of simple baselines before committing to complex modelling. - **Can Rokad improve an existing model?** Yes. We can review target definition, data, features, validation, leakage, calibration, serving, monitoring, workflow integration, and business impact rather than optimising a metric in isolation. - **How are models monitored after deployment?** Monitoring can cover data quality, feature drift, prediction distribution, latency, errors, outcomes, performance, calibration, fairness, system health, and business metrics. - **Can models run in real time or on devices?** Yes, where the data, latency, hardware, model size, update, privacy, and reliability requirements support real-time, edge, mobile, or embedded inference. --- ## [Service specialisation] Computer vision development Canonical URL: https://rokad.co/en/services/ai-development/computer-vision > Rokad develops computer-vision systems for images and video, from data and model design through edge or cloud deployment, review workflows, and monitoring. Computer vision must be designed around the camera, environment, visual variation, error cost, review process, and deployment hardware. Rokad builds detection, classification, segmentation, tracking, OCR-related, inspection, and visual analytics systems with data operations and production integration. ### Designed for - **Industrial and operational teams:** Inspect products, assets, environments, processes, and events using repeatable visual evidence. - **Product companies using cameras or imagery:** Add recognition, measurement, guidance, search, moderation, or visual interaction to a software or connected product. - **Organisations processing visual records manually:** Automate extraction, classification, triage, comparison, and review across large image or video volumes. ### Challenges - **Lab images do not represent the field:** Lighting, angle, distance, motion, background, hardware, wear, weather, and operator behaviour change model performance. - **Labels are expensive or inconsistent:** The system needs a practical annotation strategy, quality review, class definitions, edge cases, and active-learning loop. - **Inference must fit device and network constraints:** Latency, power, bandwidth, privacy, camera, compute, model size, updates, and offline operation affect the entire architecture. ### Capabilities - Vision feasibility, camera, environment, task, and error assessment - Image and video classification, detection, segmentation, tracking, and similarity - Visual inspection, measurement, OCR coordination, document image, and scene analysis - Data collection, annotation, quality review, augmentation, and active learning - Model selection, training, fine-tuning, optimisation, and evaluation - Cloud, edge, mobile, or embedded inference and device integration - Review interfaces, alerts, evidence, monitoring, retraining, and managed operation ### Solution components - **Imaging system:** Camera, optics, placement, lighting, capture timing, resolution, calibration, storage, and environmental constraints. - **Visual data operation:** Collection, consent, labelling, taxonomy, quality, versioning, difficult examples, augmentation, and retention. - **Model and inference:** Architecture, training, thresholds, latency, compression, hardware acceleration, serving, and fallback. - **Operational workflow:** Alerts, review, evidence, correction, escalation, action, analytics, feedback, and system integration. ### Use cases - **Visual quality inspection:** Detect defects, deviations, missing components, surface issues, assembly errors, or packaging problems. - **Asset and scene monitoring:** Identify objects, conditions, occupancy, movement, safety events, or changes across defined environments. - **Document and image processing:** Classify visual records, locate regions, improve OCR, extract evidence, compare images, and route review. - **Visual product capability:** Enable search, guidance, recognition, measurement, moderation, augmented workflows, or user-generated image analysis. ### Architecture and integration - **Capture before model:** Improve camera, lighting, placement, calibration, and process consistency before compensating with model complexity. - **Edge-cloud split:** Place capture, preprocessing, inference, storage, review, analytics, and training where latency, privacy, bandwidth, and hardware allow. - **Human review boundary:** Route uncertain, high-risk, novel, or policy-relevant cases to review while collecting corrections for future evaluation. ### Quality and control - **Measured behaviour:** Representative evaluation data, quality criteria, failure modes, and release thresholds are defined before expanding production use. - **Controlled actions:** Permissions, policy checks, approval gates, audit trails, fallbacks, and escalation paths govern consequential AI behaviour. - **Observable operation:** Inputs, outputs, retrieval, tool calls, latency, cost, model versions, and quality trends are monitored appropriately. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - Vision feasibility, environment, camera, data, and error assessment - Capture, annotation, model, inference, and workflow architecture - Data collection, labelling, quality, and versioning pipeline - Trained and evaluated vision model or integrated model system - Cloud, edge, mobile, or embedded inference implementation - Review, monitoring, feedback, retraining, and operating documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Do we need custom model training?** Not always. We compare existing APIs, foundation models, open models, fine-tuning, classical vision, and custom training based on task specificity, data, accuracy, latency, privacy, and cost. - **Can computer vision run without a constant internet connection?** Yes. Edge or device inference can support offline and low-latency operation, subject to hardware, model size, update, storage, and power constraints. - **How much labelled data is required?** It depends on task complexity, variation, class balance, pre-trained model suitability, error tolerance, and capture consistency. We use pilots and learning curves to estimate the data requirement. - **Can operators review uncertain results?** Yes. We can provide confidence-based routing, evidence views, correction interfaces, escalation, audit history, and feedback into future evaluation or training. --- ## [Service specialisation] MLOps services Canonical URL: https://rokad.co/en/services/ai-development/mlops > Rokad establishes reproducible, observable, governed operating systems for machine-learning and generative-AI models across development and production. MLOps connects experimentation with dependable operation. Rokad builds data and training pipelines, experiment tracking, registries, evaluation, deployment, model routing, monitoring, feedback, retraining, approval, rollback, and governance for predictive and generative AI systems. ### Designed for - **Data teams moving models into production:** Replace notebook handoffs and manual deployment with reproducible pipelines, artefacts, environments, and release controls. - **Product teams operating several AI capabilities:** Standardise model access, versions, evaluation, observability, cost, rollout, and incident response. - **Organisations requiring AI governance evidence:** Track data, models, evaluations, approvals, deployments, performance, changes, and ownership across the lifecycle. ### Challenges - **Experiments cannot be reproduced:** Data, code, features, parameters, environments, artefacts, and evaluation results are not consistently versioned or linked. - **Production quality is invisible:** Teams monitor infrastructure but not data drift, model performance, grounding, failures, costs, or user outcomes. - **Model changes lack release discipline:** New versions, prompts, providers, indexes, or features reach users without regression evidence, approval, canaries, or rollback. ### Capabilities - Data, feature, training, evaluation, and artefact pipelines - Experiment tracking, lineage, registries, model cards, and reproducibility - Batch, online, streaming, edge, and generative-AI deployment - Evaluation suites, regression gates, approval, canary, shadow, and rollback - Data quality, drift, performance, latency, cost, error, and safety monitoring - Feedback, labelling, retraining, reindexing, and continuous improvement - Access, environment, audit, documentation, incident, and governance operations ### Solution components - **Development system:** Versioned data, code, configuration, features, prompts, environments, experiments, artefacts, and evaluation results. - **Release system:** Registries, approvals, tests, packaging, deployment, traffic allocation, compatibility, rollback, and change records. - **Production intelligence:** Data quality, predictions, generations, retrieval, tools, latency, cost, failures, drift, outcomes, and system health. - **Improvement loop:** Feedback, sampled review, labelling, error analysis, retraining, prompt or index change, evaluation, and controlled release. ### Use cases - **Predictive-model platform:** Standardise feature, training, registry, deployment, monitoring, and retraining across several models and teams. - **Generative-AI operations:** Manage prompts, models, retrieval, evaluations, traces, providers, costs, feedback, and release gates. - **Regulated or high-assurance AI lifecycle:** Create lineage, documentation, review, approval, access, evidence, monitoring, and change-management controls. - **AI platform consolidation:** Replace duplicated provider integrations and team-specific tooling with shared services and governance. ### Architecture and integration - **Artefact lineage:** Link production behaviour to data, code, features, prompts, indexes, configuration, model, environment, evaluation, and approval. - **Separation of concerns:** Keep experimentation, orchestration, serving, evaluation, telemetry, governance, and product integration independently evolvable. - **Evidence-based release:** Require task-specific regression results, operational checks, approval, staged exposure, monitoring, and rollback before full rollout. ### Quality and control - **Measured behaviour:** Representative evaluation data, quality criteria, failure modes, and release thresholds are defined before expanding production use. - **Controlled actions:** Permissions, policy checks, approval gates, audit trails, fallbacks, and escalation paths govern consequential AI behaviour. - **Observable operation:** Inputs, outputs, retrieval, tool calls, latency, cost, model versions, and quality trends are monitored appropriately. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - MLOps current-state, requirement, and risk assessment - Data, training, evaluation, registry, deployment, and monitoring architecture - Automated pipelines, environments, artefact storage, and release workflows - Evaluation suites, quality gates, canary, shadow, and rollback controls - Production dashboards, alerts, drift, cost, and performance monitoring - Runbooks, model cards, governance, incident, and handover documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Is MLOps only for custom-trained models?** No. Generative-AI systems also need versioned prompts, model and provider changes, retrieval indexes, evaluation, traces, cost monitoring, feedback, staged release, and rollback. - **Can Rokad work with our current cloud and tooling?** Yes. We assess existing data, CI/CD, orchestration, registry, serving, monitoring, and governance capabilities before introducing additional platforms. - **What should trigger model retraining?** Retraining may follow new labelled data, drift, performance decline, changed processes, new segments, scheduled cadence, or product requirements, but each version still requires evaluation and controlled release. - **How do you roll back a model?** We preserve versioned artefacts, configuration, schemas, dependencies, traffic controls, compatibility, and deployment history so a previous approved version or deterministic fallback can be restored. --- ## [Service] Web development Canonical URL: https://rokad.co/en/services/web-development > Fast, accessible, maintainable web experiences engineered for users, content teams, search, and business operations. Rokad develops web applications, corporate and institutional websites, frontend platforms, content systems, and website modernisation programmes. Delivery connects interface quality with performance, accessibility, analytics, content operations, security, and maintainable engineering. ### Capabilities - Web application engineering - Corporate, institutional, and product websites - Frontend architecture and design systems - CMS and structured-content implementation - Performance, accessibility, SEO, and analytics - Website migration, modernisation, and managed improvement ### Challenges - **The website no longer represents the organisation:** Replace an outdated experience with a credible, measurable, maintainable digital platform. - **Frontend complexity slows product delivery:** Introduce coherent architecture, reusable components, quality controls, and a scalable design system. - **Content operations depend on developers:** Give authorised teams structured publishing workflows without compromising performance or governance. ### Service scope - **Experience and content planning:** Information architecture, user journeys, content models, interaction requirements, analytics, and conversion paths. - **Frontend and platform engineering:** Responsive interfaces, design systems, CMS integration, APIs, search, forms, authentication, and application behaviour. - **Launch and optimisation:** Migration, redirects, performance, accessibility, technical SEO, analytics, deployment, monitoring, and continuous improvement. ### Use cases - **Launch a high-trust corporate website:** Present services, evidence, research, careers, and organisational information through a credible digital platform. - **Build a complex web application:** Deliver authenticated workflows, dashboards, collaboration, data, and integrations through the browser. - **Modernise an ageing website:** Migrate content and search equity while improving design, performance, accessibility, and maintainability. - **Create a scalable frontend foundation:** Standardise components, state, testing, accessibility, and release practices across a growing product. ### Delivery process - **Discover:** Clarify the business objective, users, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, delivery plan, integrations, security controls, and operating model before implementation. - **Build and validate:** Deliver in controlled increments with review, automated testing, documentation, and stakeholder validation. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence. ### Engineering standards - **Security by design:** Threats, permissions, secrets, data boundaries, dependencies, and recovery requirements are addressed during architecture and delivery. - **Production quality:** Testing, code review, observability, deployment controls, documentation, and rollback planning are treated as delivery requirements. - **Long-term ownership:** The client receives maintainable source code, operating knowledge, technical documentation, and a practical path for future development. ### Deliverables - Information architecture and technical plan - Responsive production website or web application - Reusable component and design system - CMS schemas and publishing workflows - Performance, accessibility, and SEO validation - Analytics, deployment, and operating documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded engineering:** Specialist engineers working inside an existing product, technology, or operations team. - **Managed evolution:** Ongoing maintenance, reliability, security, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Do you design as well as develop websites?** Yes. Engagements can include information architecture, UX, visual direction, interaction design, design systems, content structure, and production engineering. - **Can Rokad preserve SEO during a migration?** Yes. We plan URL mapping, redirects, metadata, structured data, internal links, content parity, crawl controls, performance, and post-launch monitoring. - **Can non-technical teams manage content?** Yes. We can implement structured content models, roles, review workflows, previews, reusable sections, and publishing safeguards. - **Do you support accessibility and performance requirements?** Yes. Accessibility, Core Web Vitals, responsive behaviour, asset strategy, semantic markup, and performance budgets can be included in acceptance criteria. --- ## [Service specialisation] Web application development Canonical URL: https://rokad.co/en/services/web-development/web-applications > Rokad develops secure, responsive web applications with robust frontend architecture, backend integration, accessibility, performance, and production operations. Web applications combine product experience with data, identity, workflows, collaboration, integrations, and platform behaviour. Rokad develops customer portals, dashboards, operational systems, SaaS interfaces, self-service products, and specialised browser-based applications. ### Designed for - **Companies launching a browser-based product:** Build authenticated workflows, data interfaces, collaboration, transactions, and administration for real users. - **Organisations digitising customer or partner services:** Provide secure self-service, status, documents, communication, transactions, and account management. - **Teams replacing complex desktop or legacy interfaces:** Move workflows into a maintainable, accessible web platform connected to existing systems. ### Challenges - **The interface must support complex work without becoming confusing:** Dense data, workflows, roles, states, errors, and exceptions require deliberate interaction and information architecture. - **Frontend and backend behaviour drift apart:** Weak contracts, duplicated rules, inconsistent state, and unclear ownership make the product difficult to change safely. - **Performance and accessibility decline as features grow:** Bundles, data loading, rendering, components, and interaction patterns lack measurable standards and governance. ### Capabilities - Product discovery, user journeys, information architecture, and interaction design - Responsive frontend architecture, components, state, forms, and data visualisation - Authentication, organisations, roles, permissions, and account workflows - Backend, API, database, payment, communication, and third-party integration - Real-time, collaborative, offline-tolerant, and background workflows - Accessibility, performance, analytics, testing, observability, and security - Cloud deployment, release automation, documentation, and managed support ### Solution components - **Application shell:** Navigation, layout, identity, permissions, responsive behaviour, state boundaries, error handling, and accessibility. - **Workflow interfaces:** Forms, tables, dashboards, editors, steps, approvals, collaboration, notifications, and exception states. - **Data and service integration:** APIs, caching, optimistic updates, validation, real-time events, uploads, search, analytics, and external systems. - **Production operation:** Testing, releases, telemetry, performance, errors, feature controls, support, security, and continuous improvement. ### Use cases - **Customer or partner portal:** Offer secure self-service, account management, requests, documents, status, communication, and transactions. - **Operational dashboard:** Coordinate data, tasks, exceptions, approvals, collaboration, and performance across a team. - **Data-intensive application:** Provide search, filters, visualisation, comparison, editing, reporting, export, and large-data interaction. - **SaaS product interface:** Deliver multi-tenant workflows, onboarding, administration, subscriptions, collaboration, and product analytics. ### Architecture and integration - **Server and client boundary:** Place rendering, data loading, mutations, caching, security, and computation where they create the best user and operating outcome. - **State ownership:** Separate server, URL, form, local, collaborative, and derived state to reduce inconsistency and unnecessary complexity. - **Progressive resilience:** Design loading, retry, offline, partial failure, optimistic work, conflict, and recovery behaviour for real network conditions. ### Quality and control - **Accessible by default:** Semantic structure, keyboard use, contrast, responsive behaviour, and assistive-technology compatibility are treated as engineering requirements. - **Performance with evidence:** Page weight, rendering, caching, image strategy, Core Web Vitals, and runtime behaviour are measured and optimised. - **Search and content integrity:** Metadata, structured data, internal links, crawl controls, redirects, content models, and publishing workflows are implemented deliberately. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - Web-application discovery, UX, and technical architecture - Production responsive application and source code - Reusable components, design system, and interaction patterns - Backend, API, identity, data, and third-party integrations - Automated tests, accessibility, performance, and security validation - Deployment, observability, analytics, and operating documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad build the backend as well as the web interface?** Yes. We can deliver the complete product including frontend, APIs, databases, authentication, administration, integrations, infrastructure, testing, and operation. - **Can you work from an existing design system?** Yes. We can implement an established system, improve its technical foundation, close accessibility gaps, or create missing components and patterns. - **How do you manage complex frontend state?** We minimise unnecessary client state and separate server, route, form, local, collaborative, and derived state with explicit ownership and testable transitions. - **Can the web application support mobile users?** Yes. We design responsive and touch-appropriate experiences, but may recommend a native or cross-platform app when deep device, offline, notification, or store-distribution requirements justify it. --- ## [Service specialisation] Corporate website development Canonical URL: https://rokad.co/en/services/web-development/corporate-websites > Rokad designs and develops fast, accessible, content-rich corporate websites for technology companies, institutions, professional organisations, and growing businesses. A corporate website must communicate credibility, capability, evidence, and direction while supporting content operations, search, measurement, and conversion. Rokad connects information architecture, design, content systems, engineering, performance, accessibility, SEO, analytics, and long-term maintenance. ### Designed for - **Technology and services companies:** Present complex capabilities, industries, case studies, research, careers, and commercial pathways with clarity and authority. - **Institutions and research-led organisations:** Publish structured knowledge, programmes, people, evidence, reports, and organisational information through a durable platform. - **Growing organisations replacing a template website:** Move to a differentiated, scalable website that supports multiple audiences, content teams, and future expansion. ### Challenges - **The website does not explain the organisation clearly:** Services, evidence, differentiation, audiences, and calls to action are fragmented or expressed through generic language. - **Publishing depends on developers:** Content lacks structure, reusable patterns, governance, preview, roles, and a manageable editorial workflow. - **Design quality masks weak technical foundations:** Slow pages, poor accessibility, weak metadata, fragile components, and missing analytics undermine trust and discoverability. ### Capabilities - Audience, message, information-architecture, and conversion planning - Visual direction, interaction design, responsive layouts, and design systems - Service, industry, case-study, research, careers, people, and landing pages - Structured CMS, editorial roles, previews, workflows, and reusable sections - Search, forms, CRM, analytics, consent, email, and third-party integrations - Technical SEO, structured data, accessibility, performance, and security - Content migration, redirects, deployment, monitoring, and managed improvement ### Solution components - **Information system:** Audiences, journeys, hierarchy, navigation, taxonomy, page types, internal links, search, and conversion paths. - **Brand and interface system:** Visual language, typography, layout, components, media, motion, responsive behaviour, and accessibility. - **Content operation:** Models, fields, relationships, roles, review, preview, publishing, localisation, archives, and governance. - **Growth and measurement:** Search metadata, structured data, analytics, attribution, forms, CRM, experiments, performance, and ongoing improvement. ### Use cases - **Technology-services website:** Explain capabilities, specialised solutions, industries, work, research, and engagement paths to several buyer types. - **Institutional knowledge website:** Publish programmes, reports, people, events, resources, and evidence with strong taxonomy and citation-friendly structure. - **International corporate website:** Support regional content, localisation, multiple audiences, legal requirements, and market-specific conversion paths. - **Corporate replatforming:** Migrate an ageing website while preserving content, URLs, search equity, analytics continuity, and editorial operations. ### Architecture and integration - **Structured content:** Model services, sectors, work, people, publications, and relationships as reusable data rather than fixed page layouts. - **Rendering and caching:** Use static, server, edge, or hybrid rendering according to freshness, personalisation, editorial, search, and performance needs. - **Migration integrity:** Preserve canonical URLs, metadata, redirects, internal links, media, analytics, forms, and critical content during transition. ### Quality and control - **Accessible by default:** Semantic structure, keyboard use, contrast, responsive behaviour, and assistive-technology compatibility are treated as engineering requirements. - **Performance with evidence:** Page weight, rendering, caching, image strategy, Core Web Vitals, and runtime behaviour are measured and optimised. - **Search and content integrity:** Metadata, structured data, internal links, crawl controls, redirects, content models, and publishing workflows are implemented deliberately. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - Audience, message, content, and information-architecture strategy - Responsive visual design and reusable component system - Production website, templates, content models, and integrations - CMS roles, editorial workflows, previews, and documentation - Accessibility, performance, SEO, structured-data, and analytics validation - Migration, redirect, launch, monitoring, and maintenance plan ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad help structure the website content?** Yes. We can define audiences, journeys, page hierarchy, content types, service taxonomy, internal links, metadata, conversion paths, and page-level content requirements. - **Which CMS should we use?** We recommend a CMS based on content structure, editorial experience, localisation, previews, governance, integrations, hosting, performance, portability, and total ownership cost. - **Can the website support several languages?** Yes. We can design locale routing, translation workflows, content parity, language metadata, alternate links, fallback rules, search, and editorial governance. - **Can you preserve existing search rankings?** We can reduce migration risk through URL inventory, content parity, metadata, redirects, canonical rules, structured data, internal links, sitemap updates, performance, and post-launch monitoring. --- ## [Service specialisation] Frontend development Canonical URL: https://rokad.co/en/services/web-development/frontend-development > Rokad engineers scalable frontend applications and design systems for complex products, high-performance websites, and multi-team development environments. Frontend engineering determines how product behaviour, data, design, accessibility, performance, and delivery practices meet the user. Rokad builds or modernises frontend architectures, component systems, application shells, state boundaries, testing, observability, and quality standards. ### Designed for - **Product teams scaling interface complexity:** Establish architecture, patterns, components, state, testing, and ownership before inconsistency slows delivery. - **Organisations implementing a design system:** Translate design language into accessible, documented, reusable components and product integration practices. - **Teams modernising a fragile frontend:** Improve performance, dependencies, state, build systems, testing, accessibility, and release confidence incrementally. ### Challenges - **Every feature introduces a new pattern:** Components, spacing, forms, errors, data loading, state, and accessibility diverge across teams and screens. - **Frontend performance is unpredictable:** Rendering, bundles, data requests, images, third parties, and interaction costs lack budgets and ownership. - **Refactoring feels too risky:** Weak tests, tightly coupled state, old dependencies, unclear boundaries, and undocumented behaviour discourage improvement. ### Capabilities - Frontend architecture, framework, rendering, and build-system design - Application shells, navigation, routing, state, forms, and data access - Design-system components, tokens, documentation, and adoption - Accessibility, responsive behaviour, internationalisation, and input methods - Performance budgets, profiling, bundles, rendering, caching, and media - Unit, integration, visual, accessibility, and end-to-end testing - Frontend observability, error handling, release controls, and modernisation ### Solution components - **Application architecture:** Routes, layouts, rendering, boundaries, data flow, state, errors, loading, permissions, and feature organisation. - **Interface system:** Tokens, components, patterns, content, forms, feedback, accessibility, documentation, and design-to-code governance. - **Quality system:** Linting, types, tests, visual review, accessibility checks, performance budgets, telemetry, and release gates. - **Developer experience:** Local setup, build speed, previews, fixtures, mocks, documentation, ownership, contribution, and migration paths. ### Use cases - **Complex product frontend:** Build data-rich, authenticated, collaborative, workflow-heavy interfaces with clear state and error behaviour. - **Enterprise design system:** Create reusable components, patterns, tokens, documentation, testing, and contribution governance across products. - **Frontend modernisation:** Upgrade frameworks and dependencies, reduce coupling, improve state, add tests, and migrate features incrementally. - **Performance and accessibility programme:** Measure, prioritise, remediate, automate, and govern product quality across pages and releases. ### Architecture and integration - **Rendering strategy:** Choose static, server, streaming, client, edge, or hybrid rendering per route based on data, interaction, search, and performance. - **Component boundaries:** Separate primitives, patterns, features, domains, pages, and platform concerns to support reuse without abstraction debt. - **Incremental migration:** Use route, component, adapter, strangler, compatibility, and design-system adoption patterns instead of unsafe all-at-once rewrites. ### Quality and control - **Accessible by default:** Semantic structure, keyboard use, contrast, responsive behaviour, and assistive-technology compatibility are treated as engineering requirements. - **Performance with evidence:** Page weight, rendering, caching, image strategy, Core Web Vitals, and runtime behaviour are measured and optimised. - **Search and content integrity:** Metadata, structured data, internal links, crawl controls, redirects, content models, and publishing workflows are implemented deliberately. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - Frontend assessment, architecture, and modernisation plan - Production application shell, features, and source code - Design-system components, tokens, documentation, and examples - State, data, error, accessibility, and responsive patterns - Automated test suites, performance budgets, and quality checks - Build, deployment, observability, contribution, and handover documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad work with our existing designers and backend team?** Yes. We can own frontend architecture and implementation while coordinating design specifications, API contracts, testing, release practices, and shared acceptance criteria. - **Do you build design systems?** Yes. We can deliver tokens, components, patterns, documentation, accessibility, visual testing, versioning, contribution workflows, and product adoption support. - **Can a frontend be modernised incrementally?** Yes. We can migrate routes, features, components, state, build systems, and dependencies in controlled stages while maintaining product delivery. - **How do you improve frontend performance?** We measure rendering, JavaScript, data, images, fonts, caching, third parties, interactions, and user telemetry, then establish budgets and target the highest-impact constraints. --- ## [Service specialisation] CMS development Canonical URL: https://rokad.co/en/services/web-development/cms-development > Rokad implements structured content platforms that give editorial teams control while preserving performance, accessibility, search, governance, and engineering quality. A CMS should model organisational information and publishing responsibilities, not merely expose page fields. Rokad designs content types, relationships, roles, review, preview, localisation, search, APIs, frontend delivery, migration, and content operations for websites and digital products. ### Designed for - **Organisations with growing editorial operations:** Support multiple content types, teams, roles, review steps, languages, channels, and publishing schedules. - **Product teams separating content from releases:** Allow authorised users to manage product, help, marketing, knowledge, or catalogue content without code deployment. - **Companies migrating from an ageing CMS:** Improve editor experience, content structure, performance, security, integrations, and platform portability. ### Challenges - **Content is stored as page-shaped blobs:** Information cannot be reused, related, searched, localised, syndicated, or governed consistently. - **Editors can publish inconsistent experiences:** Unlimited layout freedom creates accessibility, design, performance, metadata, and maintenance problems. - **Migration scope is underestimated:** Content quality, relationships, media, URLs, metadata, permissions, workflows, and historical behaviour need explicit mapping. ### Capabilities - CMS evaluation, selection, architecture, and proof of concept - Content modelling, taxonomy, relationships, validation, and reusable sections - Roles, permissions, review, approval, preview, scheduling, and publishing - Localisation, translation workflow, variants, fallback, and content parity - Frontend integration, APIs, webhooks, search, cache, and incremental delivery - Content, media, metadata, URL, and relationship migration - Editor training, documentation, governance, monitoring, and managed support ### Solution components - **Content model:** Entities, fields, relationships, taxonomy, validation, variants, metadata, ownership, and lifecycle. - **Editorial workflow:** Roles, drafts, review, approval, preview, scheduling, publishing, rollback, audit, and collaboration. - **Delivery layer:** APIs, queries, webhooks, caching, search, rendering, images, previews, invalidation, and channel distribution. - **Content operations:** Governance, quality, accessibility, SEO, localisation, migrations, archives, analytics, training, and support. ### Use cases - **Corporate content platform:** Manage services, industries, work, people, research, careers, locations, and campaigns as related structured content. - **Multilingual publishing:** Coordinate source content, translations, locale variants, review, fallback, metadata, and release across markets. - **Product content system:** Deliver help, onboarding, announcements, feature, catalogue, policy, or educational content inside a software product. - **CMS replatforming:** Migrate content and editorial operations to a more secure, maintainable, performant, or flexible platform. ### Architecture and integration - **Content independence:** Model durable information separately from one visual layout while providing governed presentation components for editors. - **Preview and publication:** Allow accurate secure previews, staged content, scheduled release, cache invalidation, and rollback across channels. - **Portability and lock-in:** Assess export, APIs, content formats, media, extensions, custom logic, pricing, and operational dependence before selection. ### Quality and control - **Accessible by default:** Semantic structure, keyboard use, contrast, responsive behaviour, and assistive-technology compatibility are treated as engineering requirements. - **Performance with evidence:** Page weight, rendering, caching, image strategy, Core Web Vitals, and runtime behaviour are measured and optimised. - **Search and content integrity:** Metadata, structured data, internal links, crawl controls, redirects, content models, and publishing workflows are implemented deliberately. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - CMS requirements, platform comparison, and recommendation - Content model, taxonomy, roles, and workflow design - Configured or custom CMS and frontend integration - Preview, localisation, search, webhook, cache, and publishing workflows - Content, media, metadata, and URL migration - Editor training, governance, technical, and operating documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Should we use a traditional, headless, or custom CMS?** The decision depends on editorial needs, frontend flexibility, channels, previews, localisation, governance, integrations, hosting, security, portability, and total ownership cost. - **Can editors create new pages without developers?** Yes. We can provide reusable governed sections and page structures while protecting accessibility, design consistency, metadata, and performance. - **Can Rokad migrate content from our existing CMS?** Yes. We map content types, fields, relationships, media, metadata, authors, locale variants, URLs, redirects, and quality issues before rehearsed migration. - **Can the CMS publish to more than one channel?** Yes. Structured content can serve websites, applications, email, documentation, displays, feeds, or partner APIs, subject to channel-specific presentation and governance. --- ## [Platform service] WordPress development services Canonical URL: https://rokad.co/en/services/web-development/cms-development/wordpress Platform: WordPress > Rokad develops, modernises, secures, migrates, and maintains WordPress platforms with custom themes, plugins, blocks, APIs, and enterprise integrations. WordPress is most effective when content architecture, custom code, plugins, hosting, security, publishing, performance, and upgrade practices are engineered as one platform. Rokad builds maintainable WordPress systems for corporate sites, publications, portals, campaigns, and headless applications. ### Designed for - **Organisations building content-rich websites:** Create flexible editorial experiences, reusable page systems, structured content, search, localisation, and publishing workflows. - **Teams modernising an ageing WordPress estate:** Reduce plugin risk, improve security, performance, accessibility, hosting, deployment, and editorial usability. - **Enterprises requiring WordPress integrations:** Connect CRM, marketing, identity, search, analytics, ecommerce, data, and custom operational systems. ### Implementation risks - **Plugins overlap and create hidden dependencies:** Multiple extensions alter content, forms, security, caching, SEO, editing, and data without one lifecycle owner. - **Editorial flexibility produces inconsistent pages:** Uncontrolled page builders and fields allow layout, accessibility, performance, brand, and content-quality drift. - **Updates are delayed because production is fragile:** Core, PHP, themes, plugins, hosting, integrations, and database changes are not tested through a controlled release path. ### Platform capabilities - WordPress architecture, hosting, plugin, theme, content, security, and performance assessment - Custom themes, block themes, Gutenberg blocks, design systems, templates, and editor controls - Custom plugins, post types, taxonomies, fields, workflows, REST APIs, webhooks, and scheduled processing - Headless WordPress, frontend frameworks, preview, caching, search, media, and deployment - Multisite, localisation, editorial roles, approvals, revisions, governance, and content operations - CRM, forms, marketing, identity, search, analytics, ecommerce, and enterprise integrations - Migration, redirects, accessibility, SEO, security, monitoring, backups, updates, and managed maintenance ### Implementation system - **Content and editor system:** Content types, blocks, fields, taxonomy, media, roles, preview, workflow, validation, and reusable page patterns. - **Theme and plugin architecture:** Presentation, custom functionality, supported extension points, dependencies, ownership, tests, and upgrade boundaries. - **Delivery platform:** Hosting, runtime, database, cache, CDN, files, search, queues, deployment, observability, backup, and recovery. - **Digital integrations:** Forms, CRM, identity, analytics, marketing, search, ecommerce, APIs, webhooks, and data synchronisation. ### Use cases - **Corporate and institutional website:** Deliver services, research, resources, news, careers, locations, forms, governance, and multilingual content. - **Publication or knowledge platform:** Support authors, editors, taxonomies, series, search, subscriptions, related content, and structured archives. - **Headless WordPress application:** Use WordPress for editorial operations while a custom frontend serves web, mobile, or multi-channel experiences. - **WordPress rescue and modernisation:** Stabilise security, plugins, theme, hosting, database, performance, deployment, backups, and update operations. ### Architecture - **Custom functionality belongs in plugins:** Keep business logic, integrations, data structures, and scheduled work outside themes and core files. - **Editors receive constrained flexibility:** Provide reusable blocks and templates with explicit content and design controls rather than unrestricted page construction. - **Updates are production releases:** Test WordPress, PHP, themes, plugins, integrations, database, cache, and frontend behaviour before controlled deployment. ### Quality and governance - **Structured content:** Models, relationships, validation, localisation, metadata, taxonomy, and reusable presentation boundaries are defined deliberately. - **Publishing governance:** Roles, workflow, preview, approvals, scheduling, audit, environments, and recovery support controlled editorial operation. - **Frontend independence:** Content APIs, caching, rendering, search, previews, media, and deployment are engineered for reliable multi-channel delivery. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - WordPress code, content, theme, plugin, hosting, security, and performance assessment - Content model, editor, theme, plugin, integration, and infrastructure architecture - Production theme, blocks, plugins, APIs, headless frontend, or multisite implementation - Content, CRM, forms, identity, search, analytics, and marketing integrations - Migration, redirects, testing, accessibility, performance, security, and release controls - Editor, developer, administrator, support, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad build custom WordPress themes and plugins?** Yes. We develop versioned themes, blocks, plugins, APIs, workflows, integrations, settings, permissions, tests, and deployment controls. - **Can WordPress be used headlessly?** Yes. We can use WordPress for content and editorial workflows while building a separate frontend with preview, caching, media, search, and deployment. - **Can an existing WordPress site be made faster and safer?** Yes. We assess hosting, PHP, database, queries, plugins, theme, cache, CDN, images, scripts, security, backups, and update practices. - **Can Rokad maintain WordPress after launch?** Yes. Managed support can cover updates, security, monitoring, backups, performance, incidents, content workflows, integrations, and feature delivery. --- ## [Platform service] Webflow development services Canonical URL: https://rokad.co/en/services/web-development/cms-development/webflow Platform: Webflow > Rokad designs and develops Webflow websites with structured CMS, reusable components, interactions, custom code, platform integrations, and managed content operations. Webflow enables visual website production, but scalable delivery still requires information architecture, CMS modelling, component standards, accessibility, responsive behaviour, custom-code boundaries, integrations, analytics, SEO, and controlled publishing. Rokad structures the platform for long-term marketing and content ownership. ### Designed for - **Technology and professional-service companies:** Launch credible corporate, product, service, research, career, and campaign websites with strong content ownership. - **Marketing teams reducing developer dependency:** Use governed components and CMS models to publish pages and content without compromising quality. - **Organisations migrating from legacy website platforms:** Move content, design, SEO, forms, analytics, integrations, and editorial workflows into a maintainable Webflow system. ### Implementation risks - **Visual freedom creates inconsistent implementation:** Classes, spacing, components, responsive behaviour, interactions, and CMS references drift without design-system rules. - **Custom code becomes an invisible dependency:** Scripts, embeds, forms, analytics, animations, and third parties lack ownership, testing, security, and update controls. - **CMS structure follows current pages rather than reusable content:** Collections and fields are difficult to extend across resources, services, teams, locations, industries, and languages. ### Platform capabilities - Webflow information architecture, content inventory, CMS, design-system, and migration planning - Responsive page development, components, variables, class conventions, accessibility, and browser quality - CMS collections, references, taxonomies, localisation, templates, filters, search, and editorial workflows - Interactions, motion, custom JavaScript, third-party libraries, embeds, and performance controls - Webflow APIs, apps, CMS automation, forms, CRM, marketing, analytics, and custom backend integration - SEO, redirects, metadata, schema, sitemap, consent, analytics, and conversion measurement - Training, publishing governance, maintenance, optimisation, support, and continuous development ### Implementation system - **Webflow design system:** Variables, typography, spacing, classes, components, states, responsive rules, interactions, and usage guidance. - **CMS architecture:** Collections, fields, references, taxonomies, localisation, templates, editor ownership, and content lifecycle. - **Custom integration layer:** Forms, APIs, CMS automation, CRM, marketing, search, analytics, scripts, webhooks, and backend services. - **Publishing operation:** Roles, staging, review, redirects, analytics, consent, QA, backups, documentation, training, and support. ### Use cases - **Corporate website redesign:** Create service, industry, research, case-study, career, resource, and contact experiences on a governed system. - **Product marketing platform:** Support landing pages, campaigns, integrations, resources, comparisons, forms, analytics, and conversion testing. - **Webflow CMS migration:** Transfer content, media, URLs, metadata, redirects, taxonomies, forms, tracking, and editorial workflows. - **Webflow custom integration:** Connect CMS and forms with CRM, marketing, databases, search, automation, membership, and custom applications. ### Architecture - **Components before page duplication:** Build recurring structures and variants as governed components rather than copying and independently editing sections. - **CMS represents entities, not layouts:** Model people, services, articles, industries, locations, projects, and relationships independently from page presentation. - **Custom code has a controlled boundary:** Document purpose, loading, dependencies, permissions, performance, security, ownership, testing, and removal for every script. ### Quality and governance - **Structured content:** Models, relationships, validation, localisation, metadata, taxonomy, and reusable presentation boundaries are defined deliberately. - **Publishing governance:** Roles, workflow, preview, approvals, scheduling, audit, environments, and recovery support controlled editorial operation. - **Frontend independence:** Content APIs, caching, rendering, search, previews, media, and deployment are engineered for reliable multi-channel delivery. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Webflow content, CMS, design, class, script, SEO, analytics, and migration assessment - Information architecture, CMS model, component system, integration, and publishing design - Production Webflow pages, components, collections, templates, and interactions - Forms, CRM, marketing, analytics, search, API, automation, and custom-code integrations - Migration, redirect, accessibility, responsive, performance, SEO, and QA controls - Editor, designer, marketer, administrator, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad migrate an existing website to Webflow?** Yes. We inventory content, URLs, SEO, forms, analytics, scripts, integrations, design, CMS, media, and redirects before migration. - **Can Webflow connect to custom applications and APIs?** Yes. We can use Webflow APIs, webhooks, automation, serverless services, custom backends, scripts, and integration platforms according to the requirement. - **Can marketing teams safely create new pages?** Yes. We provide components, CMS templates, class rules, documentation, permissions, review, staging, QA, and publishing procedures. - **Can Rokad provide ongoing Webflow support?** Yes. Managed support can cover pages, CMS, components, custom code, integrations, analytics, performance, SEO, accessibility, and campaign delivery. --- ## [Platform service] Contentful development services Canonical URL: https://rokad.co/en/services/web-development/cms-development/contentful Platform: Contentful > Rokad designs and implements Contentful content platforms across structured modelling, localisation, applications, integrations, migration, and multi-channel delivery. Contentful provides a composable content layer for websites, applications, commerce, and digital products. Rokad defines durable content models, references, localisation, environments, roles, workflows, app extensions, APIs, migration, frontend integration, caching, preview, and publishing operations. ### Designed for - **Enterprises managing content across channels:** Create shared structured content for websites, mobile applications, commerce, portals, campaigns, and partner experiences. - **Organisations replacing page-bound CMS platforms:** Separate content meaning from presentation while preserving editor usability, preview, governance, and migration continuity. - **Global teams coordinating localisation:** Model shared and market-specific content, locale relationships, workflow, permissions, fallback, and publication. ### Implementation risks - **Content models mirror frontend components too closely:** Presentation changes force schema changes and prevent content reuse across channels and experiences. - **References become difficult for editors to understand:** Deep composition, generic fields, repeated entries, naming, and weak previews make publishing slow and error-prone. - **Environment and migration changes are risky:** Models, entries, locales, apps, validations, roles, and frontend releases are changed without coordinated versioning and evidence. ### Platform capabilities - Contentful organisation, space, environment, model, role, workflow, usage, and migration assessment - Content types, fields, references, validations, taxonomies, assets, metadata, and reusable composition - Localisation, locale fallback, market variants, translation workflows, and regional publishing - Content Delivery, Preview, Management, GraphQL, image, and webhook API integration - Contentful Apps, App Framework locations, custom editor interfaces, dashboards, and external data - Frontend, commerce, search, personalisation, analytics, automation, and data integration - Migration, environment promotion, testing, preview, caching, monitoring, governance, and managed operation ### Implementation system - **Content domain model:** Entities, fields, references, taxonomies, validations, assets, localisation, metadata, and ownership. - **Editorial experience:** Entry naming, views, apps, previews, workflows, roles, bulk operations, documentation, and support. - **Delivery architecture:** Delivery and preview APIs, GraphQL, caching, webhooks, frontend rendering, search, media, and deployment. - **Platform lifecycle:** Spaces, environments, migrations, releases, roles, usage, monitoring, backups, governance, and model evolution. ### Use cases - **Enterprise composable website platform:** Serve multiple brands, sites, markets, languages, teams, and frontend applications from governed content foundations. - **Commerce content layer:** Combine editorial, campaign, guide, landing, taxonomy, and merchandising content with product and commerce systems. - **Content platform migration:** Map legacy pages and entries into structured models with transformed data, references, assets, redirects, and validation. - **Custom Contentful application:** Extend editorial workflows with external data, validation, bulk actions, integrations, dashboards, and domain-specific interfaces. ### Architecture - **Model semantic entities:** Represent products, services, people, places, articles, campaigns, and relationships rather than current page sections alone. - **Environment change is versioned:** Manage content-model migrations, app changes, locale updates, validations, entries, and frontend compatibility through controlled releases. - **Preview is a product capability:** Connect draft content, routing, authentication, source maps or identifiers, frontend rendering, and editor feedback deliberately. ### Quality and governance - **Structured content:** Models, relationships, validation, localisation, metadata, taxonomy, and reusable presentation boundaries are defined deliberately. - **Publishing governance:** Roles, workflow, preview, approvals, scheduling, audit, environments, and recovery support controlled editorial operation. - **Frontend independence:** Content APIs, caching, rendering, search, previews, media, and deployment are engineered for reliable multi-channel delivery. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Contentful space, model, workflow, localisation, app, usage, and migration assessment - Content model, reference, localisation, role, workflow, and environment architecture - Production spaces, content types, validations, apps, webhooks, and platform configuration - Frontend, preview, search, commerce, analytics, automation, and data integrations - Migration scripts, model changes, data validation, testing, deployment, and monitoring - Editor, developer, administrator, migration, governance, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad design a Contentful content model?** Yes. We model entities, relationships, localisation, taxonomies, validations, metadata, composition, ownership, and editor experience around reuse and change. - **Can Contentful support several websites and applications?** Yes. We define space, environment, model, locale, permission, ownership, integration, and delivery boundaries for the required operating model. - **Can Rokad migrate content into Contentful?** Yes. We map source content, transform fields, create references, migrate assets and locales, validate results, and coordinate frontend and redirect changes. - **Can Rokad build custom Contentful apps?** Yes. We can create custom interfaces, field editors, sidebars, entry actions, dashboards, dialogs, external-data views, validation, and automation. --- ## [Platform service] Sanity development services Canonical URL: https://rokad.co/en/services/web-development/cms-development/sanity Platform: Sanity > Rokad develops Sanity content platforms with custom Studio experiences, structured schemas, GROQ, live content, frontend integration, migrations, and editorial workflows. Sanity combines a structured Content Lake with a highly customisable Studio. Rokad designs schemas, document relationships, Portable Text, validation, desk structure, custom inputs and tools, GROQ queries, live content, preview, webhooks, migrations, frontend delivery, and editorial governance. ### Designed for - **Product teams requiring a custom editorial application:** Build domain-specific editing, validation, workflows, tools, and content relationships beyond a fixed CMS interface. - **Organisations delivering live and structured experiences:** Serve websites, applications, commerce, campaigns, and products with flexible JSON content and real-time updates. - **Teams replacing rigid content platforms:** Migrate content and editorial workflows into a programmable Studio and API-first delivery architecture. ### Implementation risks - **Schema freedom creates inconsistent content design:** Documents, objects, references, Portable Text, naming, validation, and ownership diverge without modelling principles. - **Studio customisation becomes difficult to maintain:** Custom components, plugins, tools, actions, structure, dependencies, and permissions lack boundaries and version discipline. - **GROQ queries grow into hidden application logic:** Large projections, joins, fallbacks, draft logic, and transformations are duplicated across frontends and services. ### Platform capabilities - Sanity project, dataset, schema, Studio, role, usage, query, and migration assessment - Document and object schemas, references, Portable Text, validation, initial values, and content conventions - Custom Studio desk structure, inputs, previews, actions, tools, plugins, dashboards, and editor workflows - GROQ query design, projections, perspectives, source maps, live content, caching, and API integration - Preview, visual editing, webhooks, functions, automation, search, media, and external-data integration - Frontend, commerce, application, mobile, personalisation, analytics, and multi-channel delivery - Migration, dataset strategy, releases, testing, monitoring, documentation, and managed operation ### Implementation system - **Content Lake model:** Documents, objects, references, Portable Text, assets, taxonomies, validation, localisation, metadata, and ownership. - **Sanity Studio application:** Desk structure, forms, inputs, previews, actions, tools, dashboards, plugins, roles, workflows, and editor guidance. - **Query and delivery layer:** GROQ, live content, perspectives, caching, source maps, preview, webhooks, frontend rendering, and search. - **Platform lifecycle:** Projects, datasets, schema deployment, migrations, releases, permissions, usage, monitoring, support, and governance. ### Use cases - **Custom editorial operating system:** Create specialised workflows and tools for publishing, products, research, campaigns, catalogues, or digital services. - **Live content application:** Deliver near-real-time content updates to websites and applications with explicit query, caching, and rendering behaviour. - **Commerce and product content:** Manage editorial product data, buying guides, campaigns, collections, landing experiences, and references to commerce records. - **Sanity migration and redesign:** Transform legacy content into structured schemas, references, Portable Text, assets, validation, and new editorial workflows. ### Architecture - **Schema code is product code:** Version, review, test, document, deploy, and migrate schema and Studio changes with frontend compatibility in view. - **GROQ has reusable query boundaries:** Centralise common fragments, projections, image, reference, locale, and draft logic instead of duplicating it across clients. - **Studio follows editorial decisions:** Customise structure and inputs around roles, tasks, quality, relationships, exceptions, and publishing—not novelty alone. ### Quality and governance - **Structured content:** Models, relationships, validation, localisation, metadata, taxonomy, and reusable presentation boundaries are defined deliberately. - **Publishing governance:** Roles, workflow, preview, approvals, scheduling, audit, environments, and recovery support controlled editorial operation. - **Frontend independence:** Content APIs, caching, rendering, search, previews, media, and deployment are engineered for reliable multi-channel delivery. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Sanity schema, Studio, query, dataset, workflow, usage, and migration assessment - Content model, Studio, GROQ, preview, live-content, and integration architecture - Production schemas, Studio application, custom inputs, tools, actions, plugins, and workflows - Frontend, live content, preview, search, commerce, analytics, and external integrations - Migration scripts, schema changes, validation, testing, deployment, and monitoring - Editor, developer, administrator, query, migration, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad customise Sanity Studio?** Yes. We can build desk structures, inputs, previews, actions, tools, dashboards, document views, plugins, validation, and external-data interfaces. - **Can Rokad help with GROQ queries?** Yes. We design projections, references, localisation, perspectives, live queries, performance, reusable fragments, typing, and frontend data boundaries. - **Can content be migrated into Sanity?** Yes. We transform source data into documents, objects, references, Portable Text, assets, locales, metadata, and validated relationships. - **Can Rokad maintain Sanity after launch?** Yes. Managed support can cover schemas, Studio, queries, integrations, migrations, users, workflows, frontend delivery, monitoring, and new features. --- ## [Platform service] Strapi development services Canonical URL: https://rokad.co/en/services/web-development/cms-development/strapi Platform: Strapi > Rokad develops and operates Strapi headless CMS platforms with custom content models, APIs, plugins, administration, integrations, migration, and infrastructure. Strapi provides an open-source headless CMS and extensible application foundation. Rokad designs content types, components, relations, permissions, custom controllers and services, plugins, REST or GraphQL APIs, admin customisation, databases, storage, deployment, security, and frontend integration. ### Designed for - **Product teams requiring a self-hosted content API:** Control infrastructure, database, deployment, extensions, data, and network access while giving editors a managed interface. - **Companies building content-backed applications:** Use Strapi for websites, mobile applications, portals, catalogues, communities, internal systems, and multi-channel products. - **Teams replacing custom administration software:** Create content and operational models, roles, APIs, workflows, and extensions on an established platform foundation. ### Implementation risks - **CMS and application responsibilities become mixed:** Content editing, transactional workflows, authentication, business rules, jobs, and integrations are placed into Strapi without clear boundaries. - **Self-hosting introduces platform operations:** Database, storage, deployment, scaling, upgrades, security, backups, logs, email, queues, and recovery require ownership. - **Custom extensions complicate upgrades:** Plugins, admin changes, middleware, controllers, services, database changes, and dependencies lack compatibility controls. ### Platform capabilities - Strapi content, component, relation, role, plugin, API, infrastructure, and migration assessment - Collection and single types, components, dynamic zones, relations, validation, localisation, and media - REST, GraphQL, custom routes, controllers, services, policies, middleware, webhooks, and scheduled work - Custom plugins, admin extensions, fields, dashboards, actions, external data, and editorial tooling - Authentication, roles, permissions, service identities, API tokens, audit, and security controls - Database, storage, cache, queue, email, container, cloud, CI/CD, monitoring, backup, and recovery - Frontend, mobile, commerce, search, analytics, automation, migration, and managed operation ### Implementation system - **Content and application model:** Types, components, relations, dynamic zones, validation, localisation, media, ownership, and domain boundaries. - **API and extension layer:** REST, GraphQL, routes, controllers, services, policies, middleware, plugins, jobs, webhooks, and external systems. - **Administration and security:** Roles, permissions, tokens, users, workflows, custom admin, audit, validation, credentials, and support. - **Hosting and lifecycle:** Database, storage, deployment, environments, scaling, backups, monitoring, upgrades, security, and recovery. ### Use cases - **Self-hosted corporate CMS:** Manage structured website, resource, service, team, location, and campaign content on controlled infrastructure. - **Application content backend:** Provide authenticated APIs, media, localisation, editorial workflows, and domain content to web and mobile applications. - **Custom operational administration:** Extend Strapi with domain records, actions, roles, integrations, dashboards, validation, and controlled workflows. - **Strapi platform modernisation:** Upgrade code, plugins, database, hosting, security, deployment, observability, backups, and frontend integrations. ### Architecture - **Keep transactions in suitable services:** Use Strapi for content and appropriate workflows while placing payment, inventory, complex transactions, and high-risk logic behind dedicated services. - **Custom extensions follow platform boundaries:** Use supported routes, controllers, services, policies, middleware, plugins, and admin extension points with versioned tests. - **Self-hosted operation is automated:** Version infrastructure, configuration, secrets, migrations, deployment, backup, monitoring, scaling, and recovery procedures. ### Quality and governance - **Structured content:** Models, relationships, validation, localisation, metadata, taxonomy, and reusable presentation boundaries are defined deliberately. - **Publishing governance:** Roles, workflow, preview, approvals, scheduling, audit, environments, and recovery support controlled editorial operation. - **Frontend independence:** Content APIs, caching, rendering, search, previews, media, and deployment are engineered for reliable multi-channel delivery. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Strapi model, API, plugin, permission, infrastructure, security, and migration assessment - Content, API, plugin, admin, frontend, database, and hosting architecture - Production content types, APIs, controllers, services, policies, middleware, and plugins - Custom administration, authentication, search, commerce, automation, and application integrations - Deployment, database, storage, backup, monitoring, security, upgrade, and recovery controls - Editor, developer, administrator, infrastructure, support, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad self-host Strapi?** Yes. We can design and implement database, storage, containers, cloud, networking, secrets, CI/CD, monitoring, backups, scaling, and recovery. - **Can Rokad build custom Strapi plugins and APIs?** Yes. We can develop custom routes, controllers, services, policies, middleware, jobs, webhooks, admin extensions, fields, and plugins. - **Can Strapi support mobile and web applications together?** Yes. We model shared and channel-specific content, authentication, roles, localisation, media, APIs, caching, and frontend contracts. - **Can Rokad upgrade an existing Strapi project?** Yes. We assess custom code, plugins, APIs, database, admin changes, dependencies, hosting, data, tests, and frontend compatibility before staged upgrade. --- ## [Service specialisation] Website modernisation Canonical URL: https://rokad.co/en/services/web-development/website-modernization > Rokad modernises ageing websites through controlled redesign, replatforming, content migration, search preservation, performance improvement, and operational renewal. Website modernisation must protect existing content, traffic, integrations, analytics, editorial workflows, and organisational knowledge while improving the experience and technical foundation. Rokad plans and executes the transition with explicit migration, redirect, validation, launch, and monitoring controls. ### Designed for - **Organisations with an outdated public website:** Improve credibility, usability, accessibility, performance, search, content operations, and maintainability. - **Teams trapped on a difficult platform:** Move away from unsupported, insecure, expensive, inflexible, or developer-dependent website technology. - **Companies undergoing brand or service transformation:** Restructure the website around new positioning, capabilities, audiences, content, and commercial priorities. ### Challenges - **The visible redesign hides migration risk:** URLs, metadata, content, forms, analytics, media, integrations, and publishing workflows can break during launch. - **The current content structure cannot support growth:** Pages are inconsistent, duplicated, hard-coded, poorly related, and difficult for editors or search systems to understand. - **The platform is slow and expensive to change:** Legacy themes, plugins, dependencies, hosting, build systems, and manual processes create recurring risk and cost. ### Capabilities - Current-site inventory, analytics, crawl, content, platform, and risk assessment - Audience, information-architecture, content-model, and design transformation - CMS, framework, hosting, rendering, and integration replatforming - Content, media, metadata, form, user, and configuration migration - URL mapping, redirects, canonicals, structured data, and search preservation - Accessibility, performance, security, analytics, consent, and quality validation - Rehearsal, cutover, rollback, monitoring, training, and managed support ### Solution components - **Current-state inventory:** URLs, content, traffic, rankings, media, forms, scripts, integrations, templates, users, workflows, and technical dependencies. - **Target website system:** Information architecture, design system, content model, CMS, frontend, rendering, hosting, analytics, and governance. - **Migration programme:** Mapping, transformation, quality, redirects, rehearsals, freeze, cutover, validation, rollback, and issue resolution. - **Operational renewal:** Publishing, roles, training, deployment, monitoring, maintenance, security, ownership, and continuous improvement. ### Use cases - **Corporate website redesign and rebuild:** Replace the visual, content, and technical system while preserving essential traffic and operations. - **CMS migration:** Move structured content, media, users, workflows, metadata, and delivery to a more suitable platform. - **Performance and accessibility renewal:** Improve rendering, assets, code, content, interaction, semantics, keyboard use, and quality governance. - **Service and content architecture expansion:** Restructure a small website into a scalable system for services, solutions, sectors, work, research, and localisation. ### Architecture and integration - **URL continuity:** Preserve or intentionally redirect valuable URLs and maintain canonical, alternate, sitemap, and internal-link consistency. - **Content transformation:** Map unstructured pages into reusable content types while preserving meaning, metadata, relationships, and editorial ownership. - **Rehearsed cutover:** Test migration, redirects, forms, analytics, permissions, performance, crawl, and rollback before the production switch. ### Quality and control - **Accessible by default:** Semantic structure, keyboard use, contrast, responsive behaviour, and assistive-technology compatibility are treated as engineering requirements. - **Performance with evidence:** Page weight, rendering, caching, image strategy, Core Web Vitals, and runtime behaviour are measured and optimised. - **Search and content integrity:** Metadata, structured data, internal links, crawl controls, redirects, content models, and publishing workflows are implemented deliberately. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - Website, content, analytics, SEO, accessibility, and platform assessment - Target information architecture, design system, content model, and technical plan - Production website, CMS, integrations, and deployment configuration - Content, media, metadata, URL, redirect, and analytics migration - Accessibility, performance, security, search, and launch validation - Training, monitoring, maintenance, and post-launch improvement plan ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Can a redesign preserve our current SEO performance?** Risk can be reduced through crawl and analytics inventory, content parity, URL mapping, redirects, metadata, canonicals, structured data, internal links, sitemaps, performance, and post-launch monitoring. - **Do we need to migrate all existing content?** Not necessarily. We classify content to retain, improve, merge, redirect, archive, or remove based on value, accuracy, traffic, relevance, and future information architecture. - **Can the old and new website run in parallel?** Yes, during development and migration. Production coexistence is also possible for phased sections, but routing, content ownership, analytics, and search signals need careful control. - **Can Rokad continue maintaining the website after launch?** Yes. Managed support can include content-system support, releases, security, monitoring, performance, analytics, experimentation, and continuous development. --- ## [Service] Mobile app development Canonical URL: https://rokad.co/en/services/mobile-app-development > Mobile products engineered around real user journeys, reliable backend systems, security, and sustainable release operations. Rokad develops customer, workforce, partner, and connected-product applications for iOS and Android. We select native or cross-platform delivery based on product requirements, device capabilities, performance, team structure, and long-term operating economics. ### Capabilities - Mobile product discovery and UX - Cross-platform React Native and Flutter applications - Native iOS and Android development - Backend, API, identity, payment, and notification integration - Offline workflows, device capabilities, and connected products - Testing, store release, analytics, monitoring, and maintenance ### Challenges - **A service needs a dependable mobile channel:** Translate web or operational capabilities into a mobile experience designed around context, speed, and device behaviour. - **One codebase must serve both platforms:** Use a sustainable cross-platform architecture without compromising critical native capabilities or product quality. - **A mobile application is difficult to maintain:** Improve architecture, test coverage, release practices, observability, performance, and backend integration. ### Service scope - **Product and platform strategy:** User journeys, platform choice, offline requirements, device capabilities, backend dependencies, analytics, and release planning. - **Application engineering:** Interface, state, storage, networking, notifications, payments, authentication, device features, and backend integration. - **Release and operation:** Testing, signing, store submission, staged rollout, crash monitoring, analytics, support, and continuous delivery. ### Use cases - **Customer mobile product:** Deliver account, transaction, content, communication, booking, or service workflows on iOS and Android. - **Field and workforce application:** Support secure operational workflows, data capture, offline use, approvals, and device-assisted work. - **Companion application:** Connect users to hardware, IoT devices, subscriptions, support, configuration, and real-time status. - **Modernise an existing mobile app:** Improve stability, architecture, performance, usability, release reliability, and platform compatibility. ### Delivery process - **Discover:** Clarify the business objective, users, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, delivery plan, integrations, security controls, and operating model before implementation. - **Build and validate:** Deliver in controlled increments with review, automated testing, documentation, and stakeholder validation. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence. ### Engineering standards - **Security by design:** Threats, permissions, secrets, data boundaries, dependencies, and recovery requirements are addressed during architecture and delivery. - **Production quality:** Testing, code review, observability, deployment controls, documentation, and rollback planning are treated as delivery requirements. - **Long-term ownership:** The client receives maintainable source code, operating knowledge, technical documentation, and a practical path for future development. ### Deliverables - Mobile product and platform plan - Production iOS and Android application - Backend and third-party integrations - Automated test coverage and release pipeline - Store assets and submission support - Analytics, crash reporting, and operating documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded engineering:** Specialist engineers working inside an existing product, technology, or operations team. - **Managed evolution:** Ongoing maintenance, reliability, security, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Should we choose native or cross-platform development?** The decision depends on device capabilities, performance, UX expectations, roadmap, team structure, code sharing, release cadence, and total ownership cost. We document the trade-offs before selecting the approach. - **Can Rokad build the backend as well?** Yes. We can deliver the application, APIs, databases, authentication, notifications, administration, integrations, cloud infrastructure, and operating controls. - **Do you handle App Store and Play Store release?** Yes. We support signing, build configuration, store assets, privacy declarations, submission, review responses, staged rollout, and release monitoring. - **Can the app work offline?** Yes, where the workflow requires it. We design local storage, synchronisation, conflict handling, queued actions, security, and recovery around the operating environment. --- ## [Service specialisation] Cross-platform mobile app development Canonical URL: https://rokad.co/en/services/mobile-app-development/cross-platform > Rokad builds cross-platform mobile applications that share product and engineering foundations while preserving platform quality, performance, and native integration. Cross-platform development can improve delivery economics when product requirements, device capabilities, team structure, and performance expectations support it. Rokad designs React Native or Flutter applications with platform-aware UX, native modules, backend integration, testing, releases, and long-term maintenance. ### Designed for - **Companies launching on iOS and Android together:** Use a shared product and code foundation to reduce duplicated delivery while maintaining platform-appropriate behaviour. - **Product teams replacing two diverging applications:** Consolidate shared capabilities, design systems, business logic, testing, and release practices where it creates value. - **Web teams expanding into mobile:** Build a mobile-specific experience while sharing suitable types, APIs, design tokens, validation, and domain logic. ### Challenges - **Code sharing is treated as the only objective:** Excessive abstraction can reduce platform quality, complicate native capabilities, and create framework-specific technical debt. - **Native dependencies become the release bottleneck:** SDK changes, permissions, build systems, plugins, signing, and store policies still require platform expertise. - **The application behaves like a wrapped website:** Navigation, gestures, offline use, lifecycle, accessibility, notifications, and device capabilities need mobile-specific design. ### Capabilities - React Native and Flutter product architecture - Platform-aware UX, navigation, components, and design systems - Authentication, APIs, payments, notifications, deep links, and analytics - Offline storage, synchronisation, background work, and conflict handling - Camera, location, Bluetooth, files, biometrics, sensors, and native modules - Automated testing, build pipelines, signing, store release, and staged rollout - Crash reporting, performance, updates, version support, and managed maintenance ### Solution components - **Shared product core:** Domain logic, data access, validation, state, design tokens, components, tests, and cross-platform workflows. - **Platform adaptation:** Navigation, permissions, lifecycle, accessibility, keyboard, gestures, device APIs, builds, and store behaviour. - **Backend and device integration:** Identity, APIs, storage, notifications, deep links, payments, analytics, native modules, and offline synchronisation. - **Release operation:** Builds, signing, environments, testing, store submission, staged rollout, crashes, updates, and compatibility. ### Use cases - **Customer service application:** Deliver account, transaction, booking, communication, content, loyalty, and support workflows on both platforms. - **Marketplace or commerce application:** Support discovery, listings, cart, booking, payment, messaging, order status, fulfilment, and notifications. - **Field operations application:** Capture data, images, location, tasks, evidence, approvals, and offline work across a distributed workforce. - **Companion application:** Connect users to devices, subscriptions, configuration, telemetry, support, firmware, and cloud services. ### Architecture and integration - **Shared-versus-native boundary:** Share stable product logic and interface patterns while isolating platform-specific capabilities and release concerns. - **Offline-first decisions:** Define local authority, synchronisation, conflicts, queued actions, expiry, security, and user feedback where connectivity is unreliable. - **Framework lifecycle:** Plan dependency, SDK, plugin, operating-system, build-tool, and store-policy upgrades as ongoing product operations. ### Quality and control - **Platform-appropriate experience:** Navigation, interaction, accessibility, permissions, lifecycle behaviour, and device capabilities follow the expectations of each platform. - **Release reliability:** Automated builds, test coverage, signing, staged rollout, crash reporting, version support, and rollback planning reduce release risk. - **Secure mobile operation:** Local data, authentication, API access, secrets, device permissions, offline behaviour, and telemetry are designed around the threat model. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - Cross-platform suitability and mobile product assessment - React Native or Flutter architecture and platform plan - Production iOS and Android application and source code - Backend, native capability, payment, notification, and analytics integrations - Automated tests, build, signing, release, and store configuration - Crash, performance, version-support, and operating documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Should we use React Native or Flutter?** The decision depends on team capabilities, existing code, UI requirements, native integrations, ecosystem, performance, long-term ownership, and product roadmap. We evaluate both against the actual application. - **Will the app look and behave correctly on both platforms?** Yes. We share appropriate product foundations while adapting navigation, components, permissions, accessibility, lifecycle, and interaction to iOS and Android expectations. - **Can cross-platform apps use native device features?** Yes. We can integrate supported libraries or develop native modules for camera, Bluetooth, location, biometrics, files, sensors, background work, and other platform capabilities. - **Can Rokad migrate existing native apps to one codebase?** Yes, where the economics and product requirements justify it. We map shared features, platform-specific behaviour, backend contracts, data, releases, and staged user migration. --- ## [Service specialisation] iOS app development Canonical URL: https://rokad.co/en/services/mobile-app-development/ios > Rokad develops native iOS applications with platform-appropriate UX, secure backend integration, device capabilities, testing, store release, and ongoing support. Native iOS development is appropriate when product quality, Apple frameworks, device capabilities, performance, privacy, or platform-specific experience justify a dedicated implementation. Rokad builds Swift and SwiftUI applications for customers, workforces, connected products, and specialised workflows. ### Designed for - **Products prioritising Apple users:** Deliver a deeply platform-appropriate experience with focused optimisation for iPhone and iPad customers. - **Applications using Apple-specific capabilities:** Integrate platform frameworks, devices, privacy controls, background behaviour, biometrics, media, health, location, or accessories. - **Teams modernising an existing iOS application:** Improve architecture, Swift adoption, UI frameworks, tests, performance, accessibility, dependencies, and releases. ### Challenges - **The product needs more than lowest-common-denominator mobile behaviour:** Platform conventions, performance, device capabilities, and Apple frameworks materially affect product value. - **OS and SDK evolution creates recurring maintenance:** Framework, privacy, background, store, signing, and device changes require deliberate version and release management. - **Store review and privacy requirements are discovered late:** Data use, permissions, account deletion, subscriptions, content, tracking, and policy need to be designed before submission. ### Capabilities - Native Swift and SwiftUI application architecture - iPhone, iPad, responsive layouts, navigation, and accessibility - Authentication, APIs, payments, subscriptions, notifications, and deep links - Camera, media, location, biometrics, files, Bluetooth, sensors, and Apple frameworks - Offline storage, synchronisation, background tasks, and data protection - XCTest, UI testing, build automation, signing, TestFlight, and App Store release - Crash, performance, analytics, privacy, version support, and maintenance ### Solution components - **Native product experience:** Apple navigation, components, gestures, typography, accessibility, lifecycle, input, and device adaptation. - **Platform integration:** Notifications, subscriptions, sign-in, biometrics, background work, files, media, location, Bluetooth, and system services. - **Data and backend:** Secure APIs, authentication, local storage, synchronisation, caching, uploads, analytics, and remote configuration. - **Apple release operation:** Certificates, profiles, builds, TestFlight, privacy declarations, review, phased release, crashes, and updates. ### Use cases - **Premium customer application:** Deliver a refined account, service, content, commerce, finance, or membership experience for Apple users. - **Connected-device companion:** Configure, control, monitor, update, and support hardware through Bluetooth, network, cloud, and device APIs. - **Media or creator application:** Use camera, audio, video, files, editing, sharing, background processing, and Apple media frameworks. - **Enterprise iOS application:** Support secure workforce, field, data, approval, communication, and managed-device workflows. ### Architecture and integration - **Swift concurrency and lifecycle:** Manage async work, cancellation, state, background execution, memory, and UI updates through explicit boundaries. - **Platform version strategy:** Choose minimum OS support, feature availability, fallback, testing devices, upgrade cadence, and deprecation deliberately. - **Privacy and secure storage:** Minimise data, protect credentials and local state, control permissions, declare collection, and design deletion and retention. ### Quality and control - **Platform-appropriate experience:** Navigation, interaction, accessibility, permissions, lifecycle behaviour, and device capabilities follow the expectations of each platform. - **Release reliability:** Automated builds, test coverage, signing, staged rollout, crash reporting, version support, and rollback planning reduce release risk. - **Secure mobile operation:** Local data, authentication, API access, secrets, device permissions, offline behaviour, and telemetry are designed around the threat model. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - iOS product, platform, privacy, and technical assessment - Native Swift or SwiftUI architecture and application - Backend, device, Apple-service, payment, and notification integrations - Automated tests, build automation, signing, and TestFlight configuration - App Store assets, privacy information, submission, and review support - Crash, analytics, performance, release, and maintenance documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Do you use SwiftUI or UIKit?** We select SwiftUI, UIKit, or a controlled combination based on minimum OS, interface complexity, existing code, team capabilities, accessibility, performance, and platform support. - **Can Rokad modernise an existing Objective-C or UIKit app?** Yes. We can improve architecture, introduce Swift and SwiftUI incrementally, update dependencies, add tests, improve performance, and modernise features without an all-at-once rewrite. - **Do you handle App Store submission?** Yes. We support signing, builds, TestFlight, store assets, privacy declarations, subscriptions, review notes, submission, review responses, and phased release. - **Can the application support iPad?** Yes. We can design adaptive layouts, navigation, multitasking, keyboard, pointer, orientation, and workflow changes appropriate to iPad rather than merely stretching the iPhone interface. --- ## [Service specialisation] Android app development Canonical URL: https://rokad.co/en/services/mobile-app-development/android > Rokad develops native Android applications with device-aware UX, secure backend integration, platform capabilities, testing, Play release, and ongoing support. Native Android development supports deep platform capability, device diversity, performance, offline workflows, specialised hardware, and distribution requirements. Rokad builds Kotlin and Jetpack Compose applications for customers, enterprises, field teams, connected products, and dedicated devices. ### Designed for - **Products serving broad Android markets:** Design for meaningful device, screen, network, performance, and operating-system diversity rather than one reference phone. - **Applications using Android-specific capabilities:** Integrate background work, hardware, files, device management, Bluetooth, location, camera, payments, or specialised distribution. - **Teams modernising a legacy Android application:** Improve Kotlin adoption, Compose, architecture, dependencies, tests, performance, accessibility, and release reliability. ### Challenges - **Device and OS variation affects product quality:** Screen, memory, processor, manufacturer, permissions, background limits, network, and OS versions require deliberate support strategy. - **Offline and field conditions are underestimated:** Connectivity, battery, storage, synchronisation, device sharing, updates, and physical environment shape the application architecture. - **Release behaviour differs across channels and devices:** Build variants, signing, Play tracks, managed distribution, OEM devices, policies, and staged rollout require operational control. ### Capabilities - Native Kotlin and Jetpack Compose application architecture - Phone, tablet, foldable, dedicated-device, and responsive Android interfaces - Authentication, APIs, payments, notifications, deep links, and analytics - Camera, files, location, biometrics, Bluetooth, NFC, sensors, and hardware integration - Offline storage, synchronisation, background work, and device-management workflows - Automated testing, build variants, signing, Play tracks, and managed distribution - Crash, performance, device support, security, updates, and maintenance ### Solution components - **Android product experience:** Material patterns, navigation, adaptive layout, accessibility, back behaviour, lifecycle, permissions, and device classes. - **Device and platform integration:** Notifications, background work, files, camera, location, Bluetooth, NFC, biometrics, sensors, and managed devices. - **Data and backend:** Secure APIs, local database, synchronisation, caching, uploads, analytics, remote configuration, and offline queues. - **Distribution operation:** Build variants, signing, internal tracks, Play testing, staged rollout, enterprise distribution, crashes, and updates. ### Use cases - **Mass-market customer application:** Deliver account, service, commerce, content, finance, communication, and support across diverse Android devices. - **Field and offline application:** Support tasks, forms, media, location, evidence, scanning, synchronisation, and resilient operation in variable connectivity. - **Dedicated-device application:** Operate on kiosks, tablets, handhelds, industrial devices, scanners, or managed hardware with controlled configuration. - **Connected-device companion:** Configure, control, monitor, update, and support hardware using Bluetooth, network, cloud, and device APIs. ### Architecture and integration - **Device support matrix:** Define minimum OS, screen classes, memory, hardware, manufacturers, network conditions, and test devices based on users and distribution. - **Background and offline work:** Design scheduled, deferred, foreground, retry, battery, synchronisation, and user-feedback behaviour within platform constraints. - **Build and distribution variants:** Separate environments, customers, device profiles, features, signing, channels, and configuration without uncontrolled forks. ### Quality and control - **Platform-appropriate experience:** Navigation, interaction, accessibility, permissions, lifecycle behaviour, and device capabilities follow the expectations of each platform. - **Release reliability:** Automated builds, test coverage, signing, staged rollout, crash reporting, version support, and rollback planning reduce release risk. - **Secure mobile operation:** Local data, authentication, API access, secrets, device permissions, offline behaviour, and telemetry are designed around the threat model. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - Android product, device, distribution, and technical assessment - Native Kotlin or Jetpack Compose architecture and application - Backend, device, payment, notification, and hardware integrations - Automated tests, build variants, signing, and Play configuration - Play Store or managed-distribution assets and release support - Crash, analytics, performance, device-support, and maintenance documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Do you use Jetpack Compose or XML layouts?** We select Compose, Views, or a controlled combination based on existing code, minimum OS, interface requirements, team capabilities, performance, and migration strategy. - **How do you handle Android device fragmentation?** We define a support matrix from real users and distribution, use adaptive layouts and capability checks, test representative devices, monitor production, and avoid unsupported assumptions. - **Can the app work offline for field teams?** Yes. We design local data, queued actions, media, conflict rules, synchronisation, expiry, device security, and user feedback for intermittent connectivity. - **Can Android apps be distributed outside the Play Store?** Yes. Options include managed Google Play, enterprise mobility management, private stores, OEM distribution, direct packages, or dedicated-device provisioning, subject to security and update requirements. --- ## [Service specialisation] Enterprise mobile app development Canonical URL: https://rokad.co/en/services/mobile-app-development/enterprise-mobile-apps > Rokad builds secure enterprise mobile applications for workforce, field, partner, approval, data, asset, and operational workflows. Enterprise mobile applications must work inside organisational identity, policy, device, network, data, integration, and support constraints. Rokad develops iOS, Android, and cross-platform applications with offline operation, enterprise systems integration, managed distribution, auditability, and operator control. ### Designed for - **Organisations digitising field and workforce operations:** Move tasks, forms, evidence, approvals, communication, and status from paper or fragmented tools into a governed mobile workflow. - **Enterprises extending systems beyond the desk:** Provide secure mobile access to ERP, CRM, asset, service, document, and operational capabilities. - **Companies deploying dedicated or managed devices:** Control configuration, identity, updates, permissions, application distribution, and support across an operational fleet. ### Challenges - **The workflow occurs where connectivity is unreliable:** Users need local data, queued actions, evidence capture, synchronisation, conflict handling, and clear recovery. - **Mobile access must follow enterprise policy:** Identity, device posture, data protection, permissions, audit, retention, remote control, and integration boundaries matter. - **Operational users cannot tolerate fragile interfaces:** Time pressure, gloves, sunlight, noise, shared devices, scanning, limited training, and safety change interaction design. ### Capabilities - Field, workforce, partner, approval, asset, service, and inspection applications - Enterprise SSO, directories, roles, policy, audit, and conditional access - Offline data, queued work, synchronisation, conflict, and recovery - Forms, media, scanning, signatures, location, maps, notifications, and device capabilities - ERP, CRM, asset, document, identity, communication, and data integration - Managed devices, enterprise distribution, configuration, security, and update operation - Support consoles, telemetry, analytics, service levels, and managed maintenance ### Solution components - **Operational mobile workflow:** Tasks, routes, forms, evidence, assets, approvals, communication, exceptions, and completion under field conditions. - **Enterprise identity and policy:** SSO, roles, organisational scope, device posture, conditional access, local protection, audit, retention, and remote response. - **Offline and integration layer:** Local database, synchronisation, conflicts, queues, APIs, enterprise systems, events, validation, and reconciliation. - **Fleet and service operation:** Distribution, configuration, updates, device groups, application health, support, diagnostics, analytics, and incident handling. ### Use cases - **Field service application:** Manage work orders, assets, routes, parts, evidence, customer sign-off, exceptions, and synchronisation. - **Inspection and compliance application:** Capture structured findings, media, location, signatures, corrective actions, review, and auditable records. - **Workforce approval and task application:** Provide secure access to requests, approvals, cases, documents, alerts, and time-sensitive actions. - **Warehouse or dedicated-device workflow:** Support scanning, inventory, picking, movement, verification, exceptions, and managed hardware operation. ### Architecture and integration - **Offline authority:** Define which data and actions are available locally, how conflicts resolve, what expires, and when central validation is required. - **Enterprise trust boundary:** Separate user, device, application, network, API, data, and administrator trust with least-privilege access and evidence. - **Fleet-aware release:** Coordinate versions, device groups, forced or deferred updates, compatibility, staged rollout, support, and rollback. ### Quality and control - **Platform-appropriate experience:** Navigation, interaction, accessibility, permissions, lifecycle behaviour, and device capabilities follow the expectations of each platform. - **Release reliability:** Automated builds, test coverage, signing, staged rollout, crash reporting, version support, and rollback planning reduce release risk. - **Secure mobile operation:** Local data, authentication, API access, secrets, device permissions, offline behaviour, and telemetry are designed around the threat model. ### Delivery process - **Discover:** Clarify the business outcome, users, workflows, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, data, integrations, security, operating model, delivery sequence, and technical decisions. - **Build and validate:** Deliver in controlled increments with stakeholder review, automated testing, documentation, and production-quality engineering. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence and user feedback. ### Deliverables - Workflow, field, identity, device, integration, and risk assessment - Mobile, offline, enterprise integration, and distribution architecture - Production iOS, Android, or cross-platform enterprise application - SSO, policy, audit, device, ERP, CRM, and operational integrations - Automated tests, enterprise distribution, monitoring, and support controls - User, administrator, security, deployment, and operating documentation ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded specialists:** Specialist engineers working inside an existing product, technology, data, design, or operations team. - **Managed evolution:** Ongoing reliability, security, maintenance, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Can enterprise apps work offline?** Yes. We design local storage, data scope, queued actions, validation, conflicts, synchronisation, expiry, encryption, and recovery around the actual field workflow. - **Can the app use enterprise SSO and device-management policy?** Yes. We can integrate supported identity, conditional access, managed configuration, app protection, certificate, VPN, device posture, and enterprise distribution capabilities. - **Can Rokad integrate with ERP or other internal systems?** Yes. We can use APIs, middleware, events, files, queues, or controlled adapters with validation, reconciliation, monitoring, and ownership rules. - **How are updates managed across a device fleet?** We can coordinate staged releases, device groups, minimum versions, compatibility, managed distribution, update prompts, forced upgrades where justified, telemetry, and rollback. --- ## [Service] Product engineering and prototyping Canonical URL: https://rokad.co/en/services/product-engineering-and-prototyping > Integrated product development that turns ideas into testable physical and digital systems. Rokad combines product discovery, software, embedded development, electronics support, PCB coordination, CAD, 3D modelling, prototyping, connectivity, testing, and production preparation. This integrated approach reduces the gaps that commonly appear between mechanical, electronic, software, cloud, and user-experience decisions. ### Capabilities - Product feasibility and system architecture - Embedded firmware and connected software - Electronics and PCB design coordination - CAD, enclosure, and 3D modelling - Prototype fabrication and 3D printing - Testing, supplier research, and production preparation ### Challenges - **A concept crosses several engineering disciplines:** Coordinate software, electronics, mechanics, connectivity, cloud, and user experience as one product system. - **Critical assumptions remain untested:** Build targeted prototypes that reduce technical, usability, supply, and production risk before major investment. - **A prototype needs a production path:** Identify architecture, component, tolerance, testing, certification, supplier, and lifecycle changes required for scale. ### Service scope - **Feasibility:** Requirements, system boundaries, component research, power, connectivity, mechanical constraints, cost drivers, risks, and test plan. - **Integrated prototyping:** Firmware, electronics, enclosures, applications, APIs, cloud services, interfaces, and physical prototypes. - **Production preparation:** Iteration, validation, documentation, sourcing research, test fixtures, manufacturing handoff, and lifecycle planning. ### Use cases - **Validate a connected-product concept:** Test mechanical, electronic, firmware, cloud, application, and user assumptions before production investment. - **Develop an embedded prototype:** Combine sensors, control, connectivity, firmware, enclosure, and supporting software into a working system. - **Create functional mechanical parts:** Design and fabricate enclosures, fixtures, components, and low-volume parts for evaluation or operational use. ### Delivery process - **Discover:** Clarify the business objective, users, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, delivery plan, integrations, security controls, and operating model before implementation. - **Build and validate:** Deliver in controlled increments with review, automated testing, documentation, and stakeholder validation. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence. ### Engineering standards - **Security by design:** Threats, permissions, secrets, data boundaries, dependencies, and recovery requirements are addressed during architecture and delivery. - **Production quality:** Testing, code review, observability, deployment controls, documentation, and rollback planning are treated as delivery requirements. - **Long-term ownership:** The client receives maintainable source code, operating knowledge, technical documentation, and a practical path for future development. ### Deliverables - Feasibility and system architecture package - Component, supplier, and risk assessment - Functional software or hardware prototype - CAD, enclosure, PCB, firmware, or application assets as scoped - Test findings and iteration record - Production-readiness and next-stage plan ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded engineering:** Specialist engineers working inside an existing product, technology, or operations team. - **Managed evolution:** Ongoing maintenance, reliability, security, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad handle both software and hardware?** Yes. We can coordinate the complete system or own selected workstreams across applications, firmware, cloud, electronics, CAD, prototyping, and integration. - **Does Rokad provide 3D printing?** Yes, for suitable prototypes and low-volume parts, with process and material selected for the required fit, strength, finish, heat, and tolerance. - **Can you help prepare a prototype for manufacturing?** Yes. We identify design, component, test, documentation, supplier, certification, and lifecycle changes required for the next production stage. --- ## [Service specialisation] Embedded systems development Canonical URL: https://rokad.co/en/services/product-engineering-and-prototyping/embedded-systems > Rokad develops embedded software and device systems across firmware, electronics interfaces, connectivity, diagnostics, updates, testing, and production preparation. Embedded systems sit at the boundary between physical behaviour and software control. Rokad designs firmware architecture, hardware interfaces, device state, communications, power behaviour, diagnostics, security, boot, updates, testability, and integration with applications and cloud services. ### Designed for - **Product teams building connected or intelligent devices:** Develop the firmware and device behaviour connecting sensors, controls, communications, applications, and cloud services. - **Companies replacing prototype firmware:** Move from demonstration code to maintainable architecture, diagnostics, testing, security, update, and production controls. - **Hardware teams requiring software ownership:** Add embedded architecture, driver, protocol, testing, and application integration capability to an electronics programme. ### Challenges - **Prototype behaviour is difficult to reproduce:** Timing, state, power, peripherals, errors, and environmental conditions are hidden in ad hoc firmware and manual testing. - **Field failures are difficult to diagnose:** Devices lack structured logs, health, counters, crash evidence, remote status, version identity, and recovery paths. - **Hardware revisions destabilise software:** Pin, peripheral, timing, memory, protocol, and component changes are not isolated behind clear interfaces and configuration. ### Capabilities - Embedded architecture, state machines, scheduling, and real-time behaviour - Microcontroller, processor, board-support, peripheral, sensor, actuator, and driver integration - UART, I2C, SPI, CAN, USB, Ethernet, Bluetooth, Wi-Fi, cellular, and custom protocols - Power modes, watchdogs, boot, storage, diagnostics, fault handling, and recovery - Secure boot, credentials, firmware signing, update, rollback, and device identity - Hardware-in-loop, simulation, unit, integration, manufacturing, and field testing - Mobile, web, cloud, gateway, telemetry, and fleet-management integration ### Solution components - **Firmware platform:** Boot, board support, drivers, scheduling, state, storage, diagnostics, configuration, updates, and application boundaries. - **Physical interfaces:** Sensors, actuators, buses, timing, calibration, electrical constraints, faults, and hardware revision abstraction. - **Device communication:** Protocols, pairing, security, buffering, retry, offline behaviour, commands, telemetry, and external interfaces. - **Lifecycle operation:** Manufacturing test, provisioning, versions, updates, diagnostics, support, repair, fleet evidence, and decommissioning. ### Use cases - **Sensor and control product:** Read, calibrate, process, control, alarm, log, communicate, and recover around physical inputs and outputs. - **Connected appliance or device:** Combine local operation with mobile setup, cloud telemetry, remote control, updates, support, and subscription services. - **Industrial or field controller:** Support deterministic behaviour, rugged interfaces, local safety rules, offline operation, diagnostics, and integration. - **Prototype-to-production firmware:** Restructure experimental code around modules, tests, update, security, observability, manufacturing, and field lifecycle. ### Architecture and integration - **Hardware abstraction:** Separate application behaviour from board, peripheral, and revision-specific implementation to support controlled change. - **Explicit state and failure:** Model startup, operation, sleep, communication, update, fault, degradation, reset, and recovery as testable states. - **Update before shipment:** Design secure update, version compatibility, interrupted transfer, rollback, recovery, and support workflows before devices leave control. ### Quality and control - **Requirements before geometry:** Fit, function, load, environment, power, interfaces, tolerance, material, production, and service constraints guide design decisions. - **Evidence through prototypes:** High-risk assumptions are tested with measurable prototypes, inspection, iteration, and documented findings before scale. - **Production-aware decisions:** Component availability, manufacturing method, assembly, testing, certification, repair, and lifecycle are considered early. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Embedded requirements, hardware-interface, risk, and feasibility assessment - Firmware architecture, state, protocol, security, and update design - Production firmware, drivers, configuration, diagnostics, and source code - Test harnesses, simulation, hardware-in-loop, and manufacturing checks - Application, cloud, gateway, telemetry, and device integration - Build, provisioning, update, support, and operating documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Which microcontroller or processor should we use?** Selection depends on compute, memory, peripherals, power, connectivity, real-time requirements, temperature, supply, cost, tools, security, certification, and lifecycle. - **Can Rokad work with an existing PCB?** Yes. We can review schematics, interfaces, components, constraints, existing firmware, test access, revisions, and known failures before development. - **Can firmware be updated after deployment?** Yes, where hardware and product requirements support it. We design signing, delivery, compatibility, interrupted updates, rollback, recovery, staged rollout, and fleet visibility. - **Do you develop companion applications and cloud services?** Yes. Rokad can deliver the embedded, mobile, web, API, telemetry, device-management, update, and support layers as one product system. --- ## [Service specialisation] IoT development Canonical URL: https://rokad.co/en/services/product-engineering-and-prototyping/iot > Rokad develops connected-product and IoT systems across devices, gateways, connectivity, cloud platforms, applications, security, analytics, and fleet operations. An IoT product is a distributed system with physical constraints. Rokad designs device identity, provisioning, connectivity, protocols, gateways, telemetry, commands, digital state, updates, applications, cloud services, security, observability, and fleet lifecycle as one system. ### Designed for - **Companies launching connected products:** Build the device, application, cloud, support, telemetry, control, update, and commercial service around a physical product. - **Industrial teams connecting equipment and assets:** Collect trustworthy data, monitor condition, control approved actions, integrate operations, and support field devices. - **Organisations modernising an existing device fleet:** Improve connectivity, security, observability, protocol, update, cloud, and support foundations without replacing every device. ### Challenges - **Connectivity is intermittent and expensive:** Devices need buffering, local rules, retry, compression, prioritisation, synchronisation, and clear stale-state behaviour. - **Device identity and ownership are unclear:** Manufacturing, provisioning, customers, sites, permissions, credentials, transfer, reset, and decommissioning are disconnected. - **Fleet issues cannot be diagnosed remotely:** Operators lack version, health, telemetry, connectivity, command, update, error, and support evidence across devices. ### Capabilities - IoT product, device, connectivity, protocol, security, and fleet architecture - Device identity, manufacturing provisioning, ownership, credentials, and lifecycle - MQTT, HTTP, CoAP, WebSocket, Bluetooth, cellular, LoRaWAN, gateway, and custom communication - Telemetry, command, state, buffering, retry, offline, edge, and local automation - Device registry, digital state, APIs, rules, storage, analytics, alerts, and integrations - Mobile and web applications, onboarding, configuration, control, support, and subscriptions - Firmware updates, fleet rollout, observability, security, incident response, and managed operation ### Solution components - **Device and edge layer:** Firmware, sensors, controls, local storage, protocols, gateway, diagnostics, updates, and offline behaviour. - **Connectivity and identity:** Provisioning, credentials, authentication, ownership, sessions, network choice, message delivery, and lifecycle. - **IoT cloud platform:** Registry, telemetry, commands, digital state, rules, storage, APIs, alerts, integrations, and fleet controls. - **Product and operations:** User applications, subscriptions, support, monitoring, update rollout, incidents, analytics, service, and decommissioning. ### Use cases - **Connected consumer product:** Provide setup, remote control, status, alerts, automation, updates, support, and subscription capabilities. - **Remote asset monitoring:** Collect condition and usage data, detect exceptions, support maintenance, and integrate operational systems. - **Industrial gateway system:** Connect local equipment and protocols to secure cloud services while preserving offline and local control. - **IoT fleet modernisation:** Introduce stronger identity, protocol, telemetry, update, observability, security, and operator tooling around deployed devices. ### Architecture and integration - **Desired and reported state:** Represent intended configuration and last confirmed device state separately to handle delay, offline operation, and conflict. - **Edge-cloud responsibility:** Keep safety, latency-sensitive, offline, and privacy-critical behaviour local while using cloud for coordination and insight. - **Fleet-first lifecycle:** Design manufacturing identity, provisioning, transfer, credentials, updates, support, replacement, reset, and decommissioning from the start. ### Quality and control - **Requirements before geometry:** Fit, function, load, environment, power, interfaces, tolerance, material, production, and service constraints guide design decisions. - **Evidence through prototypes:** High-risk assumptions are tested with measurable prototypes, inspection, iteration, and documented findings before scale. - **Production-aware decisions:** Component availability, manufacturing method, assembly, testing, certification, repair, and lifecycle are considered early. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - IoT product, device, connectivity, fleet, and risk assessment - Device, gateway, cloud, application, security, and lifecycle architecture - Firmware, protocols, provisioning, telemetry, command, and update implementation - IoT cloud services, registry, data, rules, APIs, alerts, and integrations - Mobile, web, operator, support, and fleet-management interfaces - Security, observability, rollout, incident, and operating documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Which connectivity technology should we use?** The choice depends on range, bandwidth, power, latency, mobility, environment, infrastructure, coverage, recurring cost, certification, security, and offline requirements. - **Can devices continue working when offline?** Yes. We define local rules, storage, queues, stale state, time, retry, synchronisation, user feedback, safety, and conflict behaviour for connectivity loss. - **How are IoT devices secured?** Controls can include unique identity, secure provisioning, scoped credentials, encryption, signed firmware, secure boot, least privilege, rotation, telemetry, update, and decommissioning. - **Can Rokad manage deployed devices?** Yes. Managed operations can cover fleet health, connectivity, telemetry, commands, firmware rollout, incidents, cloud services, security, cost, and support tooling. --- ## [Service specialisation] PCB design and development Canonical URL: https://rokad.co/en/services/product-engineering-and-prototyping/pcb-design > Rokad supports PCB development from electronic requirements and architecture through schematic, layout coordination, prototyping, testing, sourcing, and manufacturing preparation. PCB development connects product requirements, components, power, signal integrity, interfaces, mechanics, firmware, testing, availability, and manufacturing. Rokad can lead the electronic design or coordinate specialist design and fabrication partners under an integrated product-development process. ### Designed for - **Product teams creating custom electronics:** Move from modules and development boards to an integrated board designed around the product's requirements and form factor. - **Companies revising an existing PCB:** Address component availability, cost, performance, reliability, testability, certification, or manufacturing constraints. - **Hardware programmes needing integrated coordination:** Align electronics, firmware, enclosure, connectors, power, sourcing, testing, and production readiness. ### Challenges - **Electrical and mechanical decisions conflict late:** Board outline, connectors, height, thermal, antennas, mounting, enclosure, and assembly constraints are not coordinated early. - **Prototype boards cannot be tested efficiently:** Test points, programming, diagnostics, fixtures, calibration, current measurement, and production checks are missing. - **The BOM carries supply and lifecycle risk:** Components are unavailable, unauthorised, obsolete, single-sourced, over-specified, or difficult to substitute. ### Capabilities - Electronic requirements, block diagrams, interfaces, power, and component architecture - Schematic capture, component selection, design review, and library coordination - PCB stack-up, placement, routing, power, signal, RF, thermal, and mechanical coordination - BOM, alternatives, lifecycle, cost, sourcing, and supply-risk assessment - Fabrication, assembly, stencil, panel, programming, and vendor coordination - Bring-up, test points, fixtures, diagnostics, validation, revision, and failure analysis - Firmware, enclosure, certification preparation, documentation, and production handoff ### Solution components - **Electronic architecture:** Functions, processors, power, interfaces, sensors, memory, protection, communication, clocks, and component choices. - **Board implementation:** Schematic, libraries, stack-up, placement, routing, signal, power, thermal, mechanical, antenna, and DFM constraints. - **Prototype and validation:** Fabrication, assembly, bring-up, programming, measurements, fixtures, tests, failures, fixes, and revisions. - **Production package:** Gerbers, drill, drawings, pick-and-place, BOM, assembly, programming, test, revision, and supplier documentation. ### Use cases - **Custom controller board:** Integrate processor, power, sensors, controls, communications, memory, connectors, and test access into a product board. - **IoT device PCB:** Develop low-power sensing, wireless, antenna, charging, provisioning, enclosure, and manufacturing foundations. - **Carrier or interface board:** Connect compute modules, peripherals, power, industrial interfaces, expansion, protection, and mechanical constraints. - **PCB redesign for production:** Improve availability, cost, testability, assembly, reliability, thermal, signal, certification, and supplier readiness. ### Architecture and integration - **Power and interfaces first:** Validate power budgets, rails, sequencing, protection, levels, connectors, buses, bandwidth, timing, and environmental constraints early. - **Design for test:** Provide programming, measurement, isolation, calibration, fixtures, diagnostics, and production checks before layout is frozen. - **BOM resilience:** Track lifecycle, lead time, authorised sources, alternates, footprints, firmware impact, and qualification requirements. ### Quality and control - **Requirements before geometry:** Fit, function, load, environment, power, interfaces, tolerance, material, production, and service constraints guide design decisions. - **Evidence through prototypes:** High-risk assumptions are tested with measurable prototypes, inspection, iteration, and documented findings before scale. - **Production-aware decisions:** Component availability, manufacturing method, assembly, testing, certification, repair, and lifecycle are considered early. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Electronic requirements, block diagram, interface, power, and risk package - Schematic, component selection, libraries, and design-review records - PCB layout package and electrical, mechanical, thermal, and DFM coordination - BOM, alternatives, sourcing, lifecycle, and cost assessment - Prototype fabrication, assembly, bring-up, testing, and revision support - Manufacturing, programming, test, revision, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Can Rokad manufacture the PCB as well?** Rokad can coordinate fabrication, assembly, component sourcing, stencil, panelisation, programming, testing, logistics, and supplier communication through suitable partners. - **Can you redesign a board with unavailable components?** Yes. We assess functional, electrical, footprint, firmware, certification, thermal, supply, and lifecycle implications before selecting and validating alternatives. - **Do you handle firmware too?** Yes. Embedded firmware, board bring-up, drivers, diagnostics, test firmware, communication, update, and product integration can be included. - **What files are delivered for production?** Depending on scope: source design files, schematics, Gerbers, drill, fabrication drawings, pick-and-place, BOM, assembly notes, programming, test, and revision records. --- ## [Service specialisation] 3D design and CAD services Canonical URL: https://rokad.co/en/services/product-engineering-and-prototyping/3d-design > Rokad develops mechanical concepts, enclosures, components, assemblies, and production-ready CAD around functional, electronic, manufacturing, and user requirements. Good 3D design resolves function, fit, assembly, material, tolerance, environment, electronics, user interaction, manufacturing, and service together. Rokad creates conceptual and detailed CAD for prototypes, products, enclosures, fixtures, replacement parts, and low-volume production. ### Designed for - **Product teams developing physical form:** Translate requirements, electronics, interfaces, ergonomics, assembly, and manufacturing into testable mechanical design. - **Companies requiring enclosures or custom parts:** Develop purpose-built housings, mounts, brackets, adapters, fixtures, mechanisms, and assemblies. - **Teams improving an existing mechanical design:** Address fit, strength, weight, tolerance, assembly, heat, service, cost, manufacturing, and aesthetic constraints. ### Challenges - **A visually correct model does not function physically:** Clearance, tolerance, fasteners, loads, deformation, heat, cable routing, assembly, and material behaviour are missing. - **The prototype process cannot become production:** Geometry assumes additive manufacturing and ignores moulding, machining, sheet, casting, assembly, finish, and tooling constraints. - **Electronics and mechanics evolve separately:** Boards, antennas, connectors, sensors, displays, buttons, heat, mounting, and access are not controlled in one interface model. ### Capabilities - Mechanical requirements, references, measurements, interfaces, and feasibility - Concept sketches, form studies, packaging, ergonomics, and architecture - Parametric CAD, parts, assemblies, mechanisms, enclosures, and fixtures - PCB, connector, antenna, display, control, cable, thermal, and mounting integration - Tolerance, fastener, snap, seal, vent, strength, material, and assembly design - Design for additive, machining, sheet, moulding, casting, and low-volume production - Drawings, exploded views, BOM, renders, prototypes, iteration, and manufacturing handoff ### Solution components - **Mechanical architecture:** Parts, interfaces, load paths, assembly sequence, access, motion, seals, heat, electronics, and manufacturing split. - **Detailed geometry:** Features, walls, ribs, bosses, fasteners, snaps, clearances, tolerances, fillets, drafts, and surface intent. - **Prototype validation:** Fit, function, ergonomics, assembly, strength, thermal, interface, appearance, and iteration using physical parts. - **Production documentation:** CAD, drawings, dimensions, tolerances, materials, finishes, BOM, assembly, revision, and supplier communication. ### Use cases - **Electronic product enclosure:** Package PCB, battery, antenna, display, buttons, connectors, thermal, assembly, service, and user interaction. - **Functional mechanical component:** Develop brackets, adapters, mounts, housings, ducts, guides, fixtures, covers, and replacement parts. - **Prototype mechanism:** Test motion, linkage, alignment, force, retention, adjustment, wear, assembly, and operating geometry. - **Design-for-manufacture revision:** Adapt an existing model to the selected material, process, tolerance, tooling, assembly, finish, and production volume. ### Architecture and integration - **Interface control:** Version board, connector, component, mount, envelope, cable, and external interfaces so parallel work remains aligned. - **Tolerance by function:** Assign clearances and tolerances from fit, movement, sealing, alignment, process capability, and assembly sequence. - **Process-aware geometry:** Design wall, draft, support, tool access, bend, undercut, machining, shrink, and finish around the intended manufacturing method. ### Quality and control - **Requirements before geometry:** Fit, function, load, environment, power, interfaces, tolerance, material, production, and service constraints guide design decisions. - **Evidence through prototypes:** High-risk assumptions are tested with measurable prototypes, inspection, iteration, and documented findings before scale. - **Production-aware decisions:** Component availability, manufacturing method, assembly, testing, certification, repair, and lifecycle are considered early. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Mechanical requirements, dimensions, interfaces, and feasibility package - Concept, packaging, form, and mechanical architecture options - Parametric part and assembly CAD source files - PCB, component, connector, thermal, cable, and mounting integration - Prototype, fit, function, tolerance, and iteration records - Drawings, materials, finishes, BOM, assembly, and manufacturing documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Can Rokad design from a sketch or physical sample?** Yes. We can work from sketches, requirements, measurements, scans, photographs, reference products, existing CAD, PCBs, and physical samples, subject to available accuracy. - **Can the design be prepared for injection moulding or machining?** Yes. We adapt geometry, wall, draft, radii, undercuts, parting, tolerances, tool access, material, finish, and assembly to the selected process. - **Do you provide renders as well as CAD?** Yes. Scope can include technical CAD, exploded views, assembly visuals, presentation renders, material studies, and manufacturing drawings. - **Can Rokad print and test the design?** Yes. We can produce suitable prototypes, assess fit and function, document findings, revise the CAD, and coordinate additional manufacturing processes. --- ## [Service specialisation] 3D printing services Canonical URL: https://rokad.co/en/services/product-engineering-and-prototyping/3d-printing > Rokad provides 3D printing for functional prototypes, enclosures, fixtures, parts, and low-volume requirements with design review and material-process selection. 3D printing is most useful when the part, material, process, orientation, tolerance, finish, and test objective are aligned. Rokad reviews models, prepares geometry, selects suitable additive processes and materials, coordinates production, and supports inspection, assembly, testing, and iteration. ### Designed for - **Product teams testing physical designs:** Evaluate fit, form, assembly, ergonomics, interfaces, mechanisms, airflow, and user interaction before tooling or production. - **Companies needing custom low-volume parts:** Produce fixtures, mounts, adapters, enclosures, covers, guides, replacement parts, and specialised components. - **Engineering teams iterating rapidly:** Move through model review, print, inspection, testing, findings, revision, and reprint under one workflow. ### Challenges - **The CAD model is not print-ready:** Walls, gaps, unsupported features, trapped volumes, tolerances, orientation, and assembly behaviour require process-specific review. - **Material names obscure functional differences:** Strength, heat, impact, creep, moisture, chemicals, UV, flexibility, finish, and anisotropy affect suitability. - **A printed prototype is mistaken for a production design:** Geometry that works additively may not transfer to moulding, machining, casting, sheet, or scaled additive production. ### Capabilities - Model review, repair, wall, tolerance, clearance, orientation, and support planning - FDM, resin, powder, service-provider, and specialist-process coordination - Material selection for fit, strength, heat, impact, flexibility, chemical, and visual needs - Functional prototypes, appearance models, enclosures, fixtures, adapters, and replacement parts - Multi-part splitting, inserts, threads, fasteners, seals, assembly, and post-processing - Dimensional inspection, fit, function, load, thermal, and iteration support - Low-volume production planning, traceability, packaging, supplier, and process transition ### Solution components - **Print objective:** Appearance, fit, assembly, function, load, thermal, fluid, ergonomic, demonstration, fixture, or end-use requirement. - **Process and material:** Resolution, strength, anisotropy, heat, finish, size, support, tolerance, cost, quantity, and lead-time trade-offs. - **Build preparation:** Model repair, orientation, supports, splitting, nesting, inserts, allowances, settings, revision, and identification. - **Validation and iteration:** Inspection, fit, assembly, test, finish, findings, revised geometry, reprint, and next-process recommendation. ### Use cases - **Product enclosure prototype:** Test board fit, connectors, buttons, display, assembly, heat, cable routing, ergonomics, and appearance. - **Engineering fixture or jig:** Produce alignment, holding, inspection, assembly, drilling, routing, test, and repeatability aids. - **Functional custom part:** Create brackets, adapters, mounts, covers, guides, ducts, handles, spacers, and replacement components. - **Low-volume pilot production:** Produce controlled small quantities for pilots, demonstrations, field evaluation, service, or specialised demand. ### Architecture and integration - **Orientation is a design decision:** Layer direction changes strength, finish, supports, tolerance, build time, failure, and post-processing requirements. - **Tolerance by process and assembly:** Clearances, holes, threads, snaps, inserts, mating surfaces, and dimensions are adjusted to machine and material behaviour. - **Prototype intent remains explicit:** Each print states what it validates and what it cannot prove about production material, process, life, or certification. ### Quality and control - **Requirements before geometry:** Fit, function, load, environment, power, interfaces, tolerance, material, production, and service constraints guide design decisions. - **Evidence through prototypes:** High-risk assumptions are tested with measurable prototypes, inspection, iteration, and documented findings before scale. - **Production-aware decisions:** Component availability, manufacturing method, assembly, testing, certification, repair, and lifecycle are considered early. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Model printability, objective, material, process, and risk review - Prepared production files, orientation, support, settings, and revision record - Printed prototypes, parts, fixtures, enclosures, or assemblies as scoped - Post-processing, inserts, threads, assembly, and finishing as scoped - Dimensional, fit, function, and test findings - Revised design recommendations and production-transition guidance ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Which 3D-printing material should we use?** Selection depends on the validation objective and requirements for strength, heat, impact, flexibility, chemical exposure, UV, moisture, finish, tolerance, quantity, and cost. - **Can you print a model created by another designer?** Yes. We review geometry, scale, units, walls, normals, gaps, tolerance, orientation, supports, assembly, and the intended test before production. - **Can printed parts be used as final products?** Sometimes. Suitability depends on material, process, loads, life, environment, consistency, finish, certification, quantity, and risk. End-use requirements are assessed explicitly. - **Can Rokad redesign a part that fails during printing or testing?** Yes. We analyse geometry, orientation, material, process, loads, tolerance, assembly, and failure evidence before revising and revalidating the part. --- ## [Service specialisation] Proof of concept development Canonical URL: https://rokad.co/en/services/product-engineering-and-prototyping/proof-of-concept > Rokad builds focused software, hardware, AI, embedded, and connected-product proofs of concept to test feasibility, integration, performance, and user assumptions. A proof of concept should reduce a defined uncertainty—not imitate a finished product badly. Rokad identifies the most consequential assumptions, designs measurable experiments, builds the smallest credible system, records evidence, and recommends whether and how to proceed. ### Designed for - **Founders and product teams evaluating a difficult concept:** Test technical feasibility, user interaction, integration, performance, hardware, data, or AI behaviour before full delivery. - **Enterprises assessing new technology:** Compare architecture, vendor, platform, automation, device, and operating assumptions in a controlled environment. - **Engineering programmes facing a high-risk dependency:** Resolve one critical unknown before committing schedule, architecture, suppliers, or production investment. ### Challenges - **The prototype has no explicit learning objective:** Features accumulate, but the team cannot state which uncertainty, threshold, or decision the work is meant to resolve. - **Demonstration shortcuts are mistaken for production architecture:** Temporary data, hardware, security, scaling, workflows, and manual operations are not labelled or planned for replacement. - **Success criteria remain subjective:** The outcome depends on visual impression rather than measured feasibility, accuracy, latency, cost, reliability, fit, or user evidence. ### Capabilities - Assumption mapping, feasibility, experiment, evidence, and decision design - Software, AI, data, embedded, electronics, IoT, CAD, and physical prototypes - Third-party API, model, hardware, cloud, vendor, and platform integration tests - Performance, latency, throughput, accuracy, power, range, fit, and reliability experiments - User workflow, interface, interaction, operator, and field validation - Prototype instrumentation, logs, measurements, findings, limitations, and risks - Production-gap assessment, architecture options, budget inputs, and next-stage roadmap ### Solution components - **Decision and hypotheses:** The decision to inform, assumptions to test, thresholds, evidence, time box, constraints, and stop conditions. - **Minimum credible system:** Only the components, integrations, interfaces, data, hardware, and workflows required to test the assumptions. - **Measurement system:** Logs, instrumentation, tests, samples, user observation, benchmarks, failure cases, and repeatable procedure. - **Production gap:** Security, reliability, scale, quality, certification, manufacturing, operations, support, cost, and maintainability still required. ### Use cases - **AI feasibility prototype:** Test task quality, data, model, latency, cost, evaluation, human review, and integration before product development. - **Connected-device prototype:** Validate sensing, control, power, connectivity, cloud, application, enclosure, and user setup assumptions. - **Integration proof:** Confirm that systems, protocols, vendors, APIs, data, identity, and workflows can coordinate under real constraints. - **Product workflow prototype:** Evaluate user journeys, interfaces, operations, permissions, exceptions, and commercial workflow before full engineering. ### Architecture and integration - **Time-boxed learning:** Limit scope by uncertainty and decision value; stop when evidence is sufficient rather than polishing non-critical features. - **Explicit shortcuts:** Document mocked, manual, insecure, non-scalable, temporary, or vendor-specific choices and their production replacements. - **Representative constraints:** Test with realistic data, hardware, environment, latency, users, volume, integration, and failure where they affect feasibility. ### Quality and control - **Requirements before geometry:** Fit, function, load, environment, power, interfaces, tolerance, material, production, and service constraints guide design decisions. - **Evidence through prototypes:** High-risk assumptions are tested with measurable prototypes, inspection, iteration, and documented findings before scale. - **Production-aware decisions:** Component availability, manufacturing method, assembly, testing, certification, repair, and lifecycle are considered early. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - PoC objective, assumptions, success criteria, risks, and experiment plan - Prototype architecture and minimum credible implementation scope - Working software, hardware, AI, data, or integrated prototype - Instrumentation, tests, demonstrations, measurements, and evidence - Findings, limitations, failures, uncertainty, and production-gap assessment - Recommendation, target options, next-stage scope, and delivery roadmap ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **How is a proof of concept different from an MVP?** A PoC primarily tests feasibility or uncertainty. An MVP is a usable product release designed to test customer and market assumptions while operating with real users. - **Can PoC code or hardware be reused in production?** Sometimes, but reuse is not assumed. We identify which components meet production standards and which require redesign for security, reliability, scale, quality, manufacturing, or operation. - **What happens if the concept fails?** A well-designed negative result is valuable. We document why it failed, which assumptions were disproved, whether alternatives exist, and whether the programme should change or stop. - **Can Rokad continue from PoC into full development?** Yes. We can translate the evidence into product discovery, architecture, production engineering, procurement, certification preparation, deployment, and managed operation. --- ## [Service] Managed technology services Canonical URL: https://rokad.co/en/services/managed-technology-services > Ongoing operation and improvement for software, AI, cloud, infrastructure, and connected products. Rokad provides accountable application maintenance, cloud and DevOps operations, observability, security maintenance, incident support, optimisation, release management, and continuous engineering. We can assume responsibility for systems built by Rokad or take over technology delivered by another team. ### Capabilities - Application maintenance and feature delivery - Cloud, infrastructure, deployment, and cost operations - Observability, incident response, backup, and recovery - Security, dependency, and vulnerability maintenance - AI quality and model operations - Reliability, performance, capacity, and service reporting ### Challenges - **A critical system lacks clear ownership:** Establish responsibility, service boundaries, access, documentation, monitoring, release controls, and escalation. - **Incidents and releases are unpredictable:** Improve observability, runbooks, deployment practices, recovery, testing, and operational discipline. - **Maintenance consumes the product roadmap:** Separate and manage reliability, security, dependencies, infrastructure, and recurring technical work. ### Service scope - **Technical baseline:** Audit code, infrastructure, access, dependencies, security, data, deployment, monitoring, documentation, and current risk. - **Managed operation:** Monitoring, maintenance, releases, incidents, backups, security, vendor coordination, reporting, and service management. - **Continuous improvement:** Performance, cost, reliability, developer experience, architecture, automation, and prioritised technical debt reduction. ### Use cases - **Take over an existing production system:** Perform a controlled handover and establish reliable technical and operational ownership. - **Stabilise a fragile application:** Address recurring failures, unsafe releases, missing visibility, performance problems, and operational risk. - **Run cloud and DevOps operations:** Manage infrastructure, deployments, observability, environments, security, cost, backup, and recovery. ### Delivery process - **Discover:** Clarify the business objective, users, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, delivery plan, integrations, security controls, and operating model before implementation. - **Build and validate:** Deliver in controlled increments with review, automated testing, documentation, and stakeholder validation. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence. ### Engineering standards - **Security by design:** Threats, permissions, secrets, data boundaries, dependencies, and recovery requirements are addressed during architecture and delivery. - **Production quality:** Testing, code review, observability, deployment controls, documentation, and rollback planning are treated as delivery requirements. - **Long-term ownership:** The client receives maintainable source code, operating knowledge, technical documentation, and a practical path for future development. ### Deliverables - Technical baseline and risk register - Service scope, ownership map, and support plan - Monitoring, alerting, deployment, backup, and recovery controls - Runbooks and operating documentation - Maintenance and security cadence - Service reporting and improvement backlog ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded engineering:** Specialist engineers working inside an existing product, technology, or operations team. - **Managed evolution:** Ongoing maintenance, reliability, security, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad support a system built by another team?** Yes. We begin with an audit and controlled handover covering code, infrastructure, access, deployment, documentation, dependencies, data, and risk. - **What does managed support include?** The scope can include monitoring, incidents, maintenance, security, releases, cloud operations, backup, performance, cost, feature delivery, and service reporting. - **Do you offer service levels?** Yes. Response targets, coverage windows, escalation, responsibilities, exclusions, dependencies, and reporting are defined according to system criticality and budget. --- ## [Service specialisation] Application maintenance services Canonical URL: https://rokad.co/en/services/managed-technology-services/application-maintenance > Rokad provides accountable application maintenance covering incidents, defects, dependencies, security, releases, performance, support, and ongoing improvement. Application maintenance is sustained technical ownership, not a queue of isolated fixes. Rokad establishes a technical baseline, service boundaries, monitoring, release controls, maintenance cadence, support workflows, documentation, and an improvement backlog around production software. ### Designed for - **Organisations without reliable software ownership:** Transfer responsibility for an application whose original developers are unavailable, overloaded, or no longer suitable. - **Product teams protecting roadmap capacity:** Separate incidents, dependencies, security, defects, upgrades, and recurring operational work from strategic feature delivery. - **Companies operating business-critical custom software:** Establish predictable releases, support, documentation, monitoring, recovery, and technical improvement. ### Challenges - **Every issue requires rediscovery:** Code, architecture, environments, data, deployment, vendors, and operating procedures are undocumented or scattered. - **Maintenance is entirely reactive:** Dependencies, capacity, performance, security, backups, and technical debt are addressed only after disruption. - **Changes cannot be released safely:** Weak tests, manual deployment, environment drift, and missing observability make even small fixes risky. ### Capabilities - Codebase, architecture, dependency, environment, data, and risk assessment - Incident, defect, request, escalation, ownership, and service workflows - Dependency, runtime, framework, database, API, and platform maintenance - Security updates, vulnerability remediation, access, secrets, and configuration - Testing, release, deployment, migration, rollback, and change controls - Performance, reliability, backup, recovery, monitoring, and cost improvement - Documentation, reporting, technical debt, roadmap support, and feature delivery ### Solution components - **Technical baseline:** Source, architecture, environments, access, dependencies, data, deployments, monitoring, incidents, backups, and risk. - **Maintenance system:** Intake, triage, priority, service target, ownership, diagnosis, fix, review, release, validation, and closure. - **Preventive programme:** Dependencies, security, capacity, performance, data, backup, recovery, documentation, and lifecycle review. - **Continuous evolution:** Technical debt, architecture, automation, user feedback, product roadmap, reporting, and improvement investment. ### Use cases - **Take over a custom application:** Perform controlled access, code, infrastructure, deployment, data, vendor, and operational handover. - **Maintain a SaaS or business platform:** Manage incidents, releases, dependencies, security, integrations, reliability, and ongoing product changes. - **Support a legacy application:** Stabilise and maintain critical software while planning selective modernisation or replacement. - **Provide overflow engineering maintenance:** Own defined applications, components, defects, upgrades, or operational work alongside an internal team. ### Architecture and integration - **Risk-based maintenance cadence:** Schedule updates from exposure, support status, criticality, change risk, compatibility, and operational windows. - **Small reversible changes:** Reduce release scope, improve tests and telemetry, preserve compatibility, and maintain rollback or roll-forward paths. - **Knowledge as a service asset:** Maintain architecture, runbooks, environments, dependencies, incidents, decisions, and support procedures with the system. ### Quality and control - **Secure by design:** Identity, permissions, secrets, data boundaries, dependencies, change controls, and recovery are addressed throughout delivery. - **Observable operation:** Metrics, logs, traces, quality, cost, failures, and service outcomes are made visible and actionable. - **Reproducible delivery:** Configuration, tests, infrastructure, pipelines, artefacts, changes, and recovery procedures are versioned and repeatable. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Application baseline, ownership, dependency, and risk assessment - Maintenance scope, priorities, service targets, and support model - Monitoring, release, test, backup, recovery, and access improvements - Dependency, security, defect, and technical-debt maintenance programme - Incident, change, release, reporting, and escalation workflows - Architecture, runbook, deployment, support, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Can Rokad maintain software built by another company?** Yes. We begin with a technical and operational assessment, access handover, risk register, documentation recovery, monitoring, and controlled first changes. - **Does maintenance include new features?** It can. The service can separate incidents and preventive maintenance from a planned feature and improvement allocation. - **How are urgent incidents handled?** Coverage, severity, response targets, escalation, access, communication, dependencies, workarounds, restoration, and follow-up are defined in the service plan. - **Can application maintenance lead into modernisation?** Yes. Maintenance evidence identifies high-cost dependencies, recurring failures, architecture constraints, and the safest sequence for modernisation. --- ## [Service specialisation] Managed DevOps services Canonical URL: https://rokad.co/en/services/managed-technology-services/managed-devops > Rokad manages production cloud and DevOps operations across infrastructure, deployments, observability, incidents, backup, recovery, security, and cost. Managed DevOps provides continuing ownership of the platform that runs software. Rokad establishes the baseline, access model, infrastructure code, deployment workflows, monitoring, incident handling, backup, recovery, security, upgrades, capacity, and service reporting. ### Designed for - **Product companies without a dedicated platform team:** Access accountable cloud and delivery operations without building every role and process internally. - **Engineering teams overloaded by production operations:** Move infrastructure, releases, incidents, backups, access, upgrades, and cost work into a managed service. - **Organisations taking over an inherited environment:** Recover access, document architecture, identify risk, stabilise operation, and establish controlled ownership. ### Challenges - **Production depends on undocumented individuals:** Credentials, commands, deployments, environments, incident knowledge, and vendor relationships are concentrated in a few people. - **Monitoring creates noise rather than action:** Alerts are disconnected from user impact, service ownership, runbooks, escalation, and diagnostic context. - **Cloud cost and reliability lack one owner:** Architecture, usage, capacity, commitments, backup, security, and service objectives are managed independently. ### Capabilities - Cloud, account, network, workload, access, vendor, and risk baseline - Infrastructure as code, configuration, environments, secrets, and identity - CI/CD, deployments, changes, approvals, migrations, and rollback - Metrics, logs, traces, alerts, synthetics, dashboards, and incident response - Backup, restore, recovery, continuity, capacity, performance, and availability - Security maintenance, patching, vulnerability, policy, and access review - Cost, tagging, budgets, utilisation, commitments, upgrades, and service reporting ### Solution components - **Managed platform baseline:** Inventory, architecture, access, dependencies, infrastructure code, environments, vendors, risk, and ownership. - **Change and release operation:** Requests, approvals, pipelines, deployments, migrations, validation, rollback, records, and communication. - **Production operation:** Monitoring, alerts, incidents, capacity, availability, backup, recovery, security, and service health. - **Service management:** Coverage, targets, escalation, reporting, cost, risks, vendors, improvement backlog, reviews, and roadmap. ### Use cases - **Managed SaaS infrastructure:** Operate environments, releases, databases, queues, storage, observability, backup, incidents, security, and cost. - **Cloud operations takeover:** Recover and document an existing estate, close urgent risk, establish service controls, and assume operations. - **Release and environment management:** Own pipelines, configuration, deployments, promotions, migrations, validation, and rollback across environments. - **Reliability and cost management:** Connect service targets, capacity, architecture, usage, commitments, incidents, and optimisation into one programme. ### Architecture and integration - **Infrastructure changes through code:** Version, review, test, and deploy infrastructure and configuration rather than relying on undocumented console changes. - **Service-oriented monitoring:** Organise telemetry and alerts around user journeys, workloads, dependencies, objectives, and required operator action. - **Recovery evidence:** Backups are not considered reliable until restore, data integrity, access, dependencies, and recovery procedures are tested. ### Quality and control - **Secure by design:** Identity, permissions, secrets, data boundaries, dependencies, change controls, and recovery are addressed throughout delivery. - **Observable operation:** Metrics, logs, traces, quality, cost, failures, and service outcomes are made visible and actionable. - **Reproducible delivery:** Configuration, tests, infrastructure, pipelines, artefacts, changes, and recovery procedures are versioned and repeatable. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Cloud and DevOps baseline, inventory, access, cost, and risk assessment - Managed-service scope, coverage, ownership, targets, and escalation plan - Infrastructure code, environments, deployment, and access controls - Observability, alerting, incident, backup, restore, and recovery systems - Security, patching, capacity, cost, upgrade, and improvement programme - Runbooks, architecture, reporting, change, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Which cloud providers can Rokad manage?** Support can cover major cloud providers, managed platforms, container environments, hybrid systems, and selected hosting vendors depending on the estate and access model. - **Do you provide 24/7 support?** Coverage is defined commercially by service criticality, response targets, escalation, staffing, dependencies, and required access. Not every system requires continuous coverage. - **Can you reduce our cloud bill?** Yes. We analyse utilisation, architecture, storage, traffic, databases, schedules, capacity, commitments, licences, idle resources, and ownership while protecting reliability. - **Can Rokad work with our internal DevOps engineers?** Yes. We can own selected services, environments, on-call areas, projects, or platform operations while maintaining shared workflows and documentation. --- ## [Service specialisation] Performance optimisation services Canonical URL: https://rokad.co/en/services/managed-technology-services/performance-optimization > Rokad diagnoses and improves software performance using production evidence across frontend, application, APIs, databases, infrastructure, networks, and workload behaviour. Performance problems usually cross several layers. Rokad establishes representative workloads and baselines, traces critical journeys, identifies constraints, tests hypotheses, implements improvements, validates user and system impact, and establishes performance budgets and monitoring. ### Designed for - **Product teams with slow or inconsistent user journeys:** Improve page, interaction, API, search, transaction, report, and background-work performance using measured evidence. - **Organisations approaching capacity constraints:** Understand throughput, saturation, queues, concurrency, database, dependency, and infrastructure limits before demand events. - **Companies spending more without getting faster:** Reduce inefficient compute, database, storage, network, caching, and architecture patterns rather than scaling blindly. ### Challenges - **Teams optimise what is easy to measure:** Local benchmarks improve while end-to-end user latency, correctness, throughput, or cost remains unchanged. - **Production load differs from test environments:** Data volume, concurrency, cache state, network, third parties, jobs, and real behaviour are not represented. - **Performance regressions return after fixes:** Budgets, tests, telemetry, ownership, capacity models, and release gates are not established. ### Capabilities - User-journey, workload, latency, throughput, error, cost, and capacity baselines - Browser, rendering, JavaScript, assets, images, fonts, network, and third-party analysis - API, service, runtime, concurrency, queue, cache, job, and dependency profiling - Database query, index, schema, lock, connection, storage, and workload optimisation - Infrastructure, container, autoscaling, network, CDN, region, and resource tuning - Load, stress, soak, spike, endurance, failure, and capacity testing - Performance budgets, regression tests, monitoring, dashboards, and operating guidance ### Solution components - **Representative baseline:** Critical journeys, datasets, traffic, concurrency, environment, cache state, dependencies, latency, throughput, and cost. - **Constraint analysis:** Profiles, traces, queries, waits, queues, saturation, errors, resources, dependencies, and causal hypotheses. - **Targeted remediation:** Code, query, index, cache, batching, async, asset, protocol, architecture, capacity, and configuration improvements. - **Regression control:** Budgets, tests, dashboards, alerts, ownership, release comparisons, capacity planning, and periodic review. ### Use cases - **Slow web or mobile backend:** Trace user journeys across client, network, API, services, database, cache, and external dependencies. - **Database bottleneck:** Improve queries, indexes, schema, transactions, locks, connections, partitions, data volume, and workload design. - **Peak-demand readiness:** Test capacity, autoscaling, queues, payments, inventory, sessions, rate limits, dependencies, and incident procedures. - **Cloud cost-performance optimisation:** Match workloads, resources, scheduling, storage, traffic, caching, architecture, and commitments to service outcomes. ### Architecture and integration - **Measure end to end:** Optimise from user action to completed outcome rather than treating individual component speed as the objective. - **Queue and concurrency awareness:** Model arrival rate, service time, contention, backpressure, retries, timeouts, pools, and saturation under realistic load. - **Budgets at design boundaries:** Allocate latency, payload, query, resource, dependency, and cost budgets across the path and enforce them continuously. ### Quality and control - **Secure by design:** Identity, permissions, secrets, data boundaries, dependencies, change controls, and recovery are addressed throughout delivery. - **Observable operation:** Metrics, logs, traces, quality, cost, failures, and service outcomes are made visible and actionable. - **Reproducible delivery:** Configuration, tests, infrastructure, pipelines, artefacts, changes, and recovery procedures are versioned and repeatable. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Performance objective, workload, telemetry, and baseline assessment - End-to-end traces, profiles, query, capacity, and constraint analysis - Prioritised remediation plan with expected impact and risk - Application, database, frontend, infrastructure, and configuration improvements - Load, stress, regression, capacity, and validation results - Performance budgets, dashboards, alerts, runbooks, and operating guidance ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Can performance be improved without rewriting the application?** Often yes. High-impact changes may involve queries, indexes, caching, payloads, assets, batching, concurrency, configuration, resources, queues, or a small number of critical paths. - **Do you perform load testing?** Yes. We define representative scenarios, data, arrival patterns, concurrency, dependencies, objectives, monitoring, safe limits, and result interpretation before testing. - **Can Rokad optimise frontend performance?** Yes. We analyse rendering, JavaScript, data, assets, images, fonts, caching, third parties, interactions, devices, networks, and real-user measurements. - **How do you prevent regressions?** We establish budgets, automated tests where practical, production telemetry, release comparisons, dashboards, alerts, ownership, and periodic capacity review. --- ## [Service specialisation] Security maintenance services Canonical URL: https://rokad.co/en/services/managed-technology-services/security-maintenance > Rokad provides continuous technical security maintenance across applications, dependencies, cloud, access, secrets, configuration, vulnerabilities, and remediation operations. Security degrades as software, dependencies, infrastructure, users, vendors, threats, and configurations change. Rokad establishes asset and ownership visibility, maintenance cadence, detection, prioritisation, remediation, exceptions, access review, evidence, and reporting around the running system. ### Designed for - **Companies operating software without a security maintenance function:** Create a practical recurring programme for vulnerabilities, dependencies, access, secrets, cloud, and application controls. - **Product teams preparing for customer assurance:** Maintain evidence and operational discipline for security reviews, questionnaires, audits, and enterprise requirements. - **Organisations with unmanageable scanner findings:** Connect findings to assets, reachability, criticality, ownership, remediation, exceptions, and closure evidence. ### Challenges - **Security work is periodic rather than continuous:** Annual reviews cannot keep pace with dependency, cloud, access, secret, configuration, and threat changes. - **Findings lack operational context:** Severity alone does not identify exposure, exploitability, asset value, reachable paths, compensating controls, or safe remediation. - **Exceptions become permanent risk:** Suppressed findings and deferred changes lack owners, scope, reason, expiry, approval, review, and alternative controls. ### Capabilities - Asset, service, dependency, owner, environment, data, and exposure inventory - Dependency, runtime, container, operating system, cloud, and application maintenance - Source, secret, vulnerability, configuration, identity, and access review - Finding enrichment, reachability, priority, remediation, validation, and closure - Credential, key, certificate, token, account, privilege, and rotation operations - Logging, alert, audit, backup, recovery, security evidence, and incident follow-up - Exception, risk, metric, reporting, customer assurance, and continuous improvement ### Solution components - **Security inventory:** Assets, services, owners, dependencies, identities, environments, data, vendors, exposure, criticality, and lifecycle. - **Detection and intake:** Advisories, scans, cloud findings, access events, incidents, tests, vendor notices, and reported weaknesses. - **Remediation system:** Context, priority, owner, plan, change, testing, validation, exception, closure, and communication. - **Assurance operation:** Metrics, evidence, reviews, access recertification, exceptions, reporting, questionnaires, and control improvement. ### Use cases - **Dependency and vulnerability maintenance:** Track supported versions, advisories, exposure, upgrades, compatibility, testing, exceptions, and remediation evidence. - **Cloud security maintenance:** Review identity, network, storage, encryption, logging, secrets, backups, public exposure, policy, and configuration drift. - **Access and secret lifecycle:** Manage accounts, privileges, service credentials, keys, certificates, tokens, rotation, termination, and review. - **Security assurance support:** Maintain technical evidence, architecture records, remediation status, exceptions, metrics, and customer-review responses. ### Architecture and integration - **Prioritise reachable risk:** Combine severity with asset criticality, exposure, code path, privileges, data, exploitability, compensating controls, and change risk. - **Maintenance windows with emergency path:** Use regular safe updates while preserving accelerated assessment and release for actively exploited or critical weaknesses. - **Evidence from normal operation:** Generate access, change, scan, remediation, backup, recovery, deployment, and review evidence through managed workflows. ### Quality and control - **Secure by design:** Identity, permissions, secrets, data boundaries, dependencies, change controls, and recovery are addressed throughout delivery. - **Observable operation:** Metrics, logs, traces, quality, cost, failures, and service outcomes are made visible and actionable. - **Reproducible delivery:** Configuration, tests, infrastructure, pipelines, artefacts, changes, and recovery procedures are versioned and repeatable. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Security asset, dependency, identity, access, configuration, and risk baseline - Maintenance cadence, priority model, ownership, and remediation workflow - Dependency, vulnerability, cloud, secret, and access improvements - Finding, exception, validation, closure, and evidence controls - Security dashboards, metrics, reports, and assurance support - Runbooks, inventories, access, maintenance, and incident documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Is security maintenance the same as a security audit?** No. An audit or assessment is a point-in-time review. Security maintenance continuously manages change, findings, remediation, access, dependencies, evidence, and recurring controls. - **Can Rokad work with existing scanners and security vendors?** Yes. We assess signal quality, coverage, integration, ownership, workflow, and cost before adding or replacing tools. - **How quickly are vulnerabilities fixed?** Targets are based on severity, exploit activity, exposure, asset criticality, available remediation, compatibility, compensating controls, and service risk. - **Does the service include penetration testing?** Continuous maintenance may coordinate testing and remediation, while independent penetration testing is scoped separately when required. --- ## [Service specialisation] Software rescue services Canonical URL: https://rokad.co/en/services/managed-technology-services/software-rescue > Rokad rescues troubled software projects and production systems through rapid assessment, access recovery, stabilisation, risk control, and an executable continuation plan. Software rescue is required when a system is failing operationally, delivery has stalled, ownership has collapsed, or technical risk threatens the business. Rokad quickly establishes access and evidence, protects production, identifies critical failure modes, stabilises delivery, and defines whether to repair, modernise, replace, or retire. ### Designed for - **Companies with unstable production software:** Reduce incidents, data risk, failed releases, performance failures, and dependency on unavailable individuals. - **Leaders inheriting a failed development engagement:** Recover source, infrastructure, accounts, documentation, architecture, roadmap, and commercial control. - **Teams facing a stalled or over-budget project:** Determine what exists, what works, what remains, which assumptions failed, and the least-risk path forward. ### Challenges - **Access and ownership are incomplete:** Repositories, cloud, domains, stores, databases, vendors, secrets, certificates, analytics, and documentation may be controlled by others. - **Urgency encourages unsafe changes:** Teams patch production without evidence, backups, tests, rollback, monitoring, or understanding of downstream effects. - **Stakeholders lack a trustworthy status:** Reported completion, code quality, technical debt, scope, timeline, security, and production readiness are uncertain. ### Capabilities - Emergency access, asset, source, environment, vendor, data, and ownership recovery - Production incident, security, backup, data, availability, and continuity triage - Code, architecture, dependency, infrastructure, deployment, and quality assessment - Scope, progress, defect, roadmap, team, delivery, and technical-debt reconstruction - Monitoring, rollback, release, test, backup, access, and documentation stabilisation - Critical fixes, performance, security, data, dependency, and infrastructure remediation - Repair, modernise, replace, re-team, transition, or retirement recommendation ### Solution components - **Control recovery:** Accounts, repositories, infrastructure, domains, stores, credentials, vendors, data, artefacts, contracts, and ownership. - **Production protection:** Backups, access, monitoring, incident command, change freeze, rollback, capacity, security, and continuity. - **Technical truth:** What exists, what works, failure modes, architecture, code, tests, dependencies, data, scope, readiness, and risk. - **Continuation plan:** Immediate fixes, stabilisation, roadmap, ownership, team, budget inputs, milestones, modernisation, replacement, or exit. ### Use cases - **Production application stabilisation:** Reduce incidents, protect data, restore safe releases, improve monitoring, and close critical dependencies and security risk. - **Vendor or agency transition:** Recover technical assets and knowledge, validate delivery claims, establish gaps, and transfer ownership. - **Failed product-development recovery:** Assess scope, code, architecture, design, infrastructure, quality, progress, and the credible path to launch. - **Founder or key-engineer departure:** Reconstruct system knowledge, access, operations, deployment, architecture, dependencies, and support procedures. ### Architecture and integration - **Stabilise before redesign:** Protect production, data, access, releases, backup, and observability before introducing broad architectural change. - **Evidence over reported progress:** Validate working software, deployed environments, tests, source, integrations, data, acceptance criteria, and production behaviour directly. - **Decision gates:** Use explicit evidence to decide whether each component should be retained, repaired, isolated, replaced, or retired. ### Quality and control - **Secure by design:** Identity, permissions, secrets, data boundaries, dependencies, change controls, and recovery are addressed throughout delivery. - **Observable operation:** Metrics, logs, traces, quality, cost, failures, and service outcomes are made visible and actionable. - **Reproducible delivery:** Configuration, tests, infrastructure, pipelines, artefacts, changes, and recovery procedures are versioned and repeatable. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Emergency asset, access, production, data, vendor, and risk inventory - Code, architecture, delivery, quality, security, and readiness assessment - Immediate stabilisation, monitoring, backup, release, and access controls - Critical remediation and short-term continuity work - Repair, modernisation, replacement, transition, or retirement recommendation - Prioritised roadmap, ownership, milestone, runbook, and handover package ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **How quickly can Rokad begin a software rescue?** We can begin with available evidence and access immediately after commercial and security arrangements are in place, prioritising production and ownership risk first. - **Can you rescue software with little documentation?** Yes. We reconstruct behaviour from source, infrastructure, databases, logs, users, operators, vendors, deployments, incidents, and production observation. - **Will Rokad always recommend finishing the existing codebase?** No. We compare repair, selective replacement, modernisation, rebuild, vendor transition, and retirement based on evidence, risk, time, cost, and business value. - **Can Rokad continue maintaining the system after rescue?** Yes. The rescue can transition into application maintenance, managed DevOps, modernisation, or a dedicated product-development engagement. --- ## [Service] Technology procurement Canonical URL: https://rokad.co/en/services/technology-procurement > Independent selection and procurement support from requirements through integration and lifecycle management. Rokad helps organisations identify, evaluate, source, procure, configure, and manage cloud services, software, hardware, electronics, components, and specialist vendors. Recommendations consider technical fit, commercial terms, integration, availability, support, security, lock-in, and total lifecycle cost. ### Capabilities - Cloud, SaaS, software, and licence procurement - Servers, networking, workstations, devices, and specialist hardware - Electronics, PCB, component, and supplier sourcing - Vendor comparison and technical due diligence - Commercial, risk, and total-cost evaluation - Implementation, integration, renewal, and lifecycle management ### Challenges - **Requirements are unclear or vendor-led:** Translate operational needs into neutral technical, commercial, security, and lifecycle criteria. - **The market is difficult to compare:** Evaluate alternatives across architecture, integration, availability, support, contract, cost, and lock-in. - **Procurement ends before implementation:** Connect selection with configuration, migration, integration, adoption, support, and ongoing vendor management. ### Service scope - **Requirements and market assessment:** Define specifications, constraints, quantities, geography, certifications, service expectations, and evaluation criteria. - **Evaluation and sourcing:** Research vendors, compare fit and economics, validate availability, identify risks, and support negotiation. - **Implementation and lifecycle:** Coordinate purchase, configuration, integration, documentation, renewal, support, replacement, and vendor performance. ### Use cases - **Select a critical software or cloud platform:** Compare capability, architecture, integration, security, contract, lock-in, support, and total cost before commitment. - **Source technical hardware or components:** Identify suitable equipment, electronics, components, suppliers, availability, and replacement risk. - **Rationalise technology vendors:** Reduce duplication, unmanaged renewals, inconsistent contracts, integration gaps, and unnecessary operating cost. ### Delivery process - **Discover:** Clarify the business objective, users, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, delivery plan, integrations, security controls, and operating model before implementation. - **Build and validate:** Deliver in controlled increments with review, automated testing, documentation, and stakeholder validation. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence. ### Engineering standards - **Security by design:** Threats, permissions, secrets, data boundaries, dependencies, and recovery requirements are addressed during architecture and delivery. - **Production quality:** Testing, code review, observability, deployment controls, documentation, and rollback planning are treated as delivery requirements. - **Long-term ownership:** The client receives maintainable source code, operating knowledge, technical documentation, and a practical path for future development. ### Deliverables - Requirements and specification package - Vendor and product comparison matrix - Technical, commercial, security, and risk assessment - Total-cost and lifecycle analysis - Sourcing and negotiation support - Procurement, implementation, and vendor-management plan ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded engineering:** Specialist engineers working inside an existing product, technology, or operations team. - **Managed evolution:** Ongoing maintenance, reliability, security, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Is this only product resale?** No. Rokad's value is independent technical selection, commercial evaluation, sourcing, integration, implementation, and lifecycle support. - **Can you work with vendors we already use?** Yes. We can evaluate current vendors, improve requirements and commercial terms, support renewal decisions, or identify alternatives where justified. - **Can Rokad procure internationally?** Support depends on the product, destination, supplier, quantity, compliance, logistics, and commercial structure. These constraints are assessed before commitment. --- ## [Service specialisation] Cloud procurement Canonical URL: https://rokad.co/en/services/technology-procurement/cloud > Rokad helps organisations evaluate, select, negotiate, procure, and implement cloud providers and services against technical, commercial, security, and lifecycle requirements. Cloud procurement is an architecture and operating decision as much as a commercial one. Rokad compares providers, managed services, regions, contracts, support, pricing, commitments, portability, security, migration, integration, skills, and exit implications before commitment. ### Designed for - **Organisations selecting a cloud provider:** Compare provider fit across workloads, regions, architecture, services, security, support, skills, and economics. - **Companies renewing or renegotiating cloud commitments:** Validate utilisation, future demand, architecture, discounts, support, obligations, portability, and financial risk. - **Teams evaluating hosting and managed platforms:** Choose between cloud infrastructure, PaaS, managed databases, serverless, container platforms, and specialist vendors. ### Challenges - **Provider comparisons focus on list prices:** Architecture, traffic, support, commitments, operations, skills, migration, discounts, and exit costs are omitted. - **The contract is signed before workload design is stable:** Commitments and service selections are based on uncertain demand, architecture, data, and migration assumptions. - **Cloud lock-in is discussed without precision:** Teams cannot distinguish useful managed-service leverage from avoidable dependency, data gravity, contract, skill, and exit risk. ### Capabilities - Workload, region, performance, availability, data, compliance, and support requirements - Cloud, PaaS, hosting, managed service, database, container, and specialist-vendor comparison - Architecture fit, service maturity, integration, portability, skills, and operating-model evaluation - Pricing, calculators, traffic, storage, support, commitments, licences, and total-cost modelling - Security, identity, data residency, encryption, logging, assurance, and contractual control review - Commercial options, negotiation support, commitments, credits, support, terms, and exit provisions - Procurement, migration, implementation, governance, optimisation, renewal, and vendor management ### Solution components - **Cloud requirements:** Workloads, data, regions, latency, availability, scale, support, compliance, skills, migration, and lifecycle. - **Technical evaluation:** Architecture, services, interfaces, limits, maturity, security, operations, portability, and ecosystem. - **Commercial model:** Usage, traffic, storage, support, licences, commitments, discounts, growth, variance, and exit cost. - **Adoption and governance:** Accounts, ownership, budgets, tagging, policy, migration, support, optimisation, renewal, and vendor performance. ### Use cases - **Cloud-provider selection:** Compare major and specialist providers against workload, geography, security, operating, ecosystem, and economic requirements. - **Cloud commitment negotiation:** Model demand and architecture before selecting commitment term, coverage, flexibility, support, and commercial protections. - **Managed-platform procurement:** Evaluate hosting, databases, Kubernetes, edge, observability, security, data, AI, and developer platforms. - **Cloud-vendor rationalisation:** Reduce unmanaged accounts, duplicate platforms, fragmented contracts, weak governance, and unnecessary cost. ### Architecture and integration - **Architecture before commitment:** Estimate service demand, data movement, traffic, reliability, environments, backup, and operations before commercial lock-in. - **Portability by business need:** Invest in portability where concentration, regulation, negotiation, continuity, product, or exit requirements justify the cost. - **Cost ownership from launch:** Assign accounts, tags, budgets, forecasts, anomaly response, commitments, and optimisation responsibilities with procurement. ### Quality and control - **Requirement-led selection:** Products and vendors are compared against explicit technical, commercial, security, support, availability, and lifecycle criteria. - **Total lifecycle view:** Purchase price is evaluated with integration, operation, licences, logistics, maintenance, replacement, and exit costs. - **Traceable sourcing:** Specifications, alternatives, vendor evidence, assumptions, approvals, quality checks, and supply risks are documented. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Cloud workload, service, region, security, support, and lifecycle requirements - Provider and service comparison matrix - Architecture, portability, operating-model, and risk assessment - Usage, cost, commitment, support, and total-lifecycle model - Commercial options, negotiation, procurement, and contract decision support - Implementation, governance, optimisation, renewal, and vendor-management plan ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Will Rokad recommend one cloud provider?** Where evidence supports it, yes. The result may also recommend a primary provider with selected specialist services, hybrid infrastructure, or no immediate migration. - **Can Rokad help negotiate cloud contracts?** Yes. We provide technical and financial demand models, compare offers, identify risky assumptions, and support commitment, support, credit, flexibility, and exit discussions. - **Do you receive commission from providers?** Any commercial relationship relevant to a recommendation should be disclosed. Procurement can be structured as independent advisory or include agreed sourcing relationships. - **Can Rokad implement the selected cloud platform?** Yes. We can design landing zones, migrate workloads, build infrastructure and CI/CD, establish security and observability, and provide managed operation. --- ## [Service specialisation] Software procurement Canonical URL: https://rokad.co/en/services/technology-procurement/software > Rokad helps organisations evaluate, select, procure, integrate, and manage SaaS and enterprise software against operational, technical, commercial, security, and lifecycle requirements. Software procurement should begin with the operating requirement rather than a product demonstration. Rokad defines workflows, users, data, integrations, security, service, adoption, commercial, migration, and exit criteria before comparing vendors and implementation approaches. ### Designed for - **Organisations selecting critical business software:** Evaluate CRM, ERP, finance, support, HR, data, security, collaboration, workflow, and specialist platforms. - **Companies replacing an underperforming system:** Compare renewal, reconfiguration, integration, migration, replacement, and custom-development options. - **Teams rationalising SaaS and licence spend:** Identify duplication, unused seats, unmanaged renewals, inconsistent contracts, integration gaps, and lock-in. ### Challenges - **Vendor demos follow ideal workflows:** Exceptions, permissions, data quality, integration, migration, administration, reporting, and support are not tested. - **Licensing becomes expensive after adoption:** Growth, modules, API access, storage, environments, support, users, and transaction pricing are underestimated. - **Selection ignores implementation capability:** Configuration, data, process change, training, integration, governance, and internal ownership are treated as post-purchase details. ### Capabilities - Business process, users, roles, data, reporting, integration, and service requirements - SaaS, enterprise, open-source, custom, and hybrid option evaluation - Vendor research, shortlist, RFI, RFP, demonstration, proof, and reference support - Architecture, APIs, data, identity, security, privacy, assurance, and operating review - Licence, module, user, usage, support, implementation, migration, and total-cost modelling - Commercial comparison, negotiation, terms, service levels, renewals, and exit provisions - Implementation, integration, migration, adoption, governance, and vendor-management planning ### Solution components - **Operational requirements:** Users, workflows, exceptions, roles, data, reports, volumes, locations, service, and success criteria. - **Technical fit:** Architecture, APIs, identity, data, configuration, extensibility, security, environments, operations, and portability. - **Commercial fit:** Licences, modules, usage, growth, implementation, support, renewals, discounts, indexation, and exit. - **Adoption and lifecycle:** Migration, integration, process change, training, governance, ownership, support, measurement, renewal, and replacement. ### Use cases - **Enterprise application selection:** Compare platforms against complex workflows, roles, data, integration, reporting, assurance, and service requirements. - **SaaS portfolio rationalisation:** Reduce duplicate tools, unused licences, unmanaged data, fragmented identity, weak integration, and renewal risk. - **Build-versus-buy decision:** Compare product fit, differentiation, configuration, customisation, integration, time, cost, control, and long-term ownership. - **Software renewal assessment:** Evaluate utilisation, satisfaction, performance, incidents, price changes, roadmap, alternatives, migration, and negotiation position. ### Architecture and integration - **Demonstrate real scenarios:** Use representative data, roles, exceptions, volumes, integrations, reports, and administration tasks rather than scripted demos alone. - **Data and exit before purchase:** Clarify ownership, export, APIs, formats, retention, deletion, migration assistance, fees, and continuity before dependency grows. - **Configuration over uncontrolled customisation:** Prefer supported configuration and integration where it meets requirements; document the lifecycle cost of extensions and forks. ### Quality and control - **Requirement-led selection:** Products and vendors are compared against explicit technical, commercial, security, support, availability, and lifecycle criteria. - **Total lifecycle view:** Purchase price is evaluated with integration, operation, licences, logistics, maintenance, replacement, and exit costs. - **Traceable sourcing:** Specifications, alternatives, vendor evidence, assumptions, approvals, quality checks, and supply risks are documented. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Software process, user, data, integration, security, and service requirements - Build, buy, open-source, vendor, and platform comparison - RFI or RFP, demonstration scenarios, scoring, and evidence matrix - Technical, security, commercial, implementation, and total-cost assessment - Negotiation, licence, service, renewal, and exit decision support - Implementation, migration, adoption, governance, and vendor-management plan ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Can Rokad run an RFP process?** Yes. We can define requirements, identify vendors, issue questions, manage demonstrations, score evidence, clarify responses, and support commercial evaluation. - **Will you recommend custom development instead of buying software?** Where the workflow is strategically differentiating or available products create unacceptable compromise, we may recommend custom or hybrid development with explicit cost and risk comparison. - **Can you review software security and privacy?** Yes. We can assess identity, access, data handling, encryption, logging, assurance, incident, subprocessors, retention, deletion, residency, and contractual controls. - **Can Rokad help with implementation after selection?** Yes. We can configure, integrate, migrate, test, document, train, govern, and provide ongoing vendor and lifecycle support. --- ## [Service specialisation] Hardware procurement Canonical URL: https://rokad.co/en/services/technology-procurement/hardware > Rokad helps organisations specify, compare, source, procure, deploy, and manage technology hardware across compute, networking, storage, devices, and specialist equipment. Hardware procurement connects workload, environment, support, compatibility, availability, logistics, warranty, lifecycle, energy, and total cost. Rokad develops specifications, researches options and suppliers, validates fit, supports commercial decisions, and coordinates deployment and lifecycle planning. ### Designed for - **Companies purchasing business or engineering equipment:** Source workstations, laptops, servers, storage, networking, displays, peripherals, test, and specialist hardware. - **Organisations building infrastructure or labs:** Coordinate racks, power, cooling, networks, compute, storage, backup, spares, support, and site constraints. - **Teams standardising device fleets:** Define supported configurations, suppliers, warranties, imaging, security, replacement, repair, and asset lifecycle. ### Challenges - **Specifications are copied from products:** Requirements follow vendor models rather than workload, environment, compatibility, support, lifecycle, and expansion needs. - **Purchase price hides operating cost:** Power, cooling, licences, support, spares, failures, downtime, logistics, repair, and replacement are not modelled. - **Availability changes before procurement completes:** Models, components, lead times, authorised channels, warranties, and alternatives need active validation and substitution rules. ### Capabilities - Workload, user, environment, site, compatibility, performance, and lifecycle requirements - Servers, storage, networking, workstations, mobile, edge, display, and specialist equipment - Configuration, benchmark, interface, operating-system, software, and peripheral evaluation - Vendor, distributor, channel, warranty, support, lead-time, availability, and authenticity research - Purchase, energy, licence, support, logistics, spare, downtime, and total-cost modelling - Commercial comparison, negotiation support, ordering, logistics, acceptance, and asset records - Deployment, configuration, integration, support, repair, refresh, disposal, and vendor management ### Solution components - **Hardware requirements:** Workload, performance, capacity, environment, interfaces, portability, power, support, quantity, site, and lifecycle. - **Configuration and compatibility:** CPU, accelerator, memory, storage, network, power, cooling, software, drivers, peripherals, expansion, and standards. - **Supplier and commercial evaluation:** Authorisation, stock, lead time, warranty, support, service, logistics, terms, alternatives, and total cost. - **Deployment and lifecycle:** Acceptance, asset records, imaging, configuration, integration, spares, repair, support, refresh, data removal, and disposal. ### Use cases - **Engineering workstation procurement:** Match CAD, simulation, AI, development, media, display, memory, storage, portability, and software requirements. - **Server and network infrastructure:** Specify compute, storage, switching, firewall, backup, rack, power, cooling, redundancy, and support. - **Employee device standardisation:** Define user profiles, approved models, security, management, accessories, warranty, repair, replacement, and asset lifecycle. - **Specialist lab or production equipment:** Evaluate technical fit, calibration, site, interfaces, consumables, service, training, certification, and lifecycle. ### Architecture and integration - **Benchmark the workload:** Use representative applications, datasets, concurrency, peripherals, latency, throughput, and sustained behaviour where possible. - **Standardise with controlled exceptions:** Create supported profiles that reduce operational complexity while allowing justified specialised configurations. - **Plan failure and replacement:** Define warranties, spares, repair, vendor service, data protection, temporary replacement, refresh, and end-of-life handling. ### Quality and control - **Requirement-led selection:** Products and vendors are compared against explicit technical, commercial, security, support, availability, and lifecycle criteria. - **Total lifecycle view:** Purchase price is evaluated with integration, operation, licences, logistics, maintenance, replacement, and exit costs. - **Traceable sourcing:** Specifications, alternatives, vendor evidence, assumptions, approvals, quality checks, and supply risks are documented. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Hardware workload, site, compatibility, performance, quantity, and lifecycle requirements - Configuration, product, vendor, supplier, and alternative comparison - Benchmark, compatibility, support, availability, warranty, and risk assessment - Purchase, energy, licence, support, logistics, and total-cost model - Ordering, delivery, inspection, acceptance, and deployment coordination - Asset, support, repair, refresh, disposal, and vendor-management plan ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Can Rokad source hardware internationally?** Support depends on destination, product, supplier, quantity, warranty, compliance, customs, logistics, taxes, lead time, and commercial structure. - **Can you compare custom-built and branded systems?** Yes. We compare performance, component quality, support, warranty, manageability, availability, upgrade, downtime, compatibility, and total ownership cost. - **Can Rokad deploy and configure the equipment?** Yes. Scope can include inspection, imaging, operating systems, firmware, security, networking, software, asset records, integration, testing, and handover. - **Do you provide hardware warranties directly?** Warranty responsibility depends on the selected supplier and commercial structure. Rokad can evaluate and coordinate manufacturer, distributor, reseller, or service-partner support. --- ## [Service specialisation] Electronic component procurement Canonical URL: https://rokad.co/en/services/technology-procurement/electronic-components > Rokad supports electronic component sourcing through requirements, authorised-channel research, BOM analysis, alternatives, authenticity, lifecycle, and supply-risk management. Electronic component procurement must balance electrical fit, firmware and PCB impact, authorised supply, lifecycle, lead time, quality, traceability, price, and alternatives. Rokad supports development quantities, prototypes, replacements, and production sourcing with engineering context. ### Designed for - **Product teams sourcing prototype components:** Find processors, sensors, modules, power, communication, connectors, passives, and development hardware in workable quantities. - **Companies managing BOM shortages:** Evaluate authorised stock, lead times, alternates, redesign implications, lifecycle, and qualification requirements. - **Engineering teams reducing supply-chain risk:** Identify single-source, obsolete, allocation, counterfeit, regional, quality, and lifecycle exposure before production. ### Challenges - **A part number match does not guarantee equivalence:** Electrical, timing, package, footprint, firmware, thermal, certification, quality, and lifecycle differences may matter. - **Unauthorised stock creates authenticity risk:** Traceability, storage, handling, date code, relabelling, salvage, counterfeit, and warranty evidence may be incomplete. - **Lowest unit price creates redesign cost later:** Availability, support, lifecycle, minimum quantity, lead time, yield, firmware, qualification, and replacement risk are ignored. ### Capabilities - BOM review, specifications, electrical, package, footprint, firmware, and lifecycle requirements - Semiconductor, module, sensor, communication, power, connector, passive, and electromechanical sourcing - Manufacturer, authorised distributor, approved supplier, stock, lead-time, and regional research - Alternative, cross-reference, footprint, firmware, thermal, certification, and qualification assessment - Lifecycle, obsolescence, allocation, minimum order, price break, logistics, and supply-risk analysis - Authenticity, traceability, handling, storage, inspection, testing, and quality coordination - Prototype, pilot, production, spare, last-time-buy, and vendor-management support ### Solution components - **Component requirement:** Function, ratings, tolerances, interfaces, package, footprint, environment, quality, certification, quantity, and lifecycle. - **Supply evidence:** Manufacturer status, authorised channel, stock, lead time, traceability, date code, handling, warranty, and geography. - **Alternative engineering:** Electrical, physical, firmware, thermal, test, certification, qualification, and documentation impact of substitution. - **Procurement lifecycle:** Prototype quantities, production forecast, buffers, allocation, obsolescence, spares, last-time buy, and approved suppliers. ### Use cases - **Prototype BOM sourcing:** Source development quantities of components, modules, connectors, sensors, power, and communication devices. - **Shortage and alternate search:** Identify available substitutes and document PCB, firmware, test, performance, certification, and qualification impact. - **BOM risk assessment:** Review lifecycle, sources, lead times, minimums, price, allocation, quality, counterfeit, and single-source exposure. - **Production supply support:** Coordinate forecasts, approved sources, pricing, ordering, traceability, incoming checks, buffers, and lifecycle changes. ### Architecture and integration - **Authorised sources first:** Prefer manufacturer and authorised channels; use broader sourcing only with explicit traceability, inspection, test, and risk controls. - **Alternates are engineering changes:** Treat substitutions as reviewed changes affecting electrical, mechanical, firmware, test, quality, certification, and documentation. - **Lifecycle belongs in the BOM:** Track status, sources, alternates, lead time, risk, quantity, approvals, revisions, and last review with each component. ### Quality and control - **Requirement-led selection:** Products and vendors are compared against explicit technical, commercial, security, support, availability, and lifecycle criteria. - **Total lifecycle view:** Purchase price is evaluated with integration, operation, licences, logistics, maintenance, replacement, and exit costs. - **Traceable sourcing:** Specifications, alternatives, vendor evidence, assumptions, approvals, quality checks, and supply risks are documented. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - BOM, specification, quantity, quality, lifecycle, and sourcing requirements - Manufacturer, supplier, stock, lead-time, price, and traceability comparison - Alternative-component and engineering-impact assessment - Lifecycle, obsolescence, counterfeit, allocation, and supply-risk register - Ordering, logistics, inspection, testing, and quality coordination - Approved supplier, alternate, revision, and component-lifecycle documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Can Rokad source obsolete components?** We can research remaining authorised stock, approved aftermarket sources, alternates, redesign, last-time buy, and risk controls. Availability and authenticity cannot be assumed. - **Can you confirm whether an alternate is drop-in compatible?** We compare datasheets, package, footprint, pinout, electrical, timing, thermal, firmware, certification, and test requirements. Physical fit alone is insufficient. - **How do you reduce counterfeit risk?** We prioritise authorised channels and use traceability, supplier qualification, packaging, labels, date codes, storage, inspection, electrical tests, and specialist analysis where justified. - **Can Rokad source small prototype quantities?** Yes, subject to availability, supplier minimums, logistics, handling, commercial practicality, and the required quality level. --- ## [Service specialisation] PCB fabrication and assembly procurement Canonical URL: https://rokad.co/en/services/technology-procurement/pcb-components > Rokad coordinates PCB fabrication and assembly procurement across manufacturing files, BOM sourcing, supplier evaluation, prototypes, testing, quality, logistics, and production readiness. PCB procurement is an engineering-controlled manufacturing workflow. Rokad reviews production packages, identifies missing decisions, compares fabricators and assemblers, coordinates BOM and alternatives, supports prototypes and pilot builds, and documents quality, test, revision, and logistics requirements. ### Designed for - **Product teams ordering first PCB prototypes:** Convert design files and BOM into a controlled fabrication, assembly, bring-up, and revision process. - **Companies moving from prototypes to pilot production:** Improve DFM, BOM, panel, test, programming, traceability, yield, quality, packaging, and supplier readiness. - **Engineering teams seeking alternative PCB suppliers:** Compare capability, quality, lead time, communication, price, sourcing, testing, certification, and logistics. ### Challenges - **Manufacturing packages are incomplete:** Stack-up, impedance, tolerances, finish, drawings, panel, stencil, BOM, centroid, assembly, programming, and test details conflict or are missing. - **Fabrication and assembly responsibilities are unclear:** Component sourcing, substitutions, consigned parts, stencils, tooling, programming, inspection, failures, and rework lack ownership. - **A successful prototype is assumed to be production-ready:** Yield, test coverage, traceability, panelisation, process variation, component lifecycle, packaging, and repeatability remain unvalidated. ### Capabilities - Gerber, ODB++, drill, stack-up, impedance, drawing, panel, stencil, BOM, and centroid review - PCB fabricator, assembler, turnkey, consigned, local, and international supplier evaluation - Layer, material, copper, finish, via, tolerance, controlled impedance, and DFM coordination - BOM sourcing, authorised channels, alternates, lifecycle, minimums, shortages, and substitutions - Prototype, pilot, panel, stencil, tooling, assembly, programming, inspection, and rework coordination - AOI, X-ray, electrical, functional, boundary, programming, fixture, and acceptance-test planning - Traceability, quality, yield, failures, revisions, packaging, logistics, and production handoff ### Solution components - **Fabrication package:** Board files, stack-up, materials, copper, finish, vias, impedance, dimensions, tolerances, drawings, panel, and revision. - **Assembly package:** BOM, approved alternates, centroid, drawings, polarity, process, stencil, programming, fixtures, inspection, and rework. - **Supplier and quality system:** Capability, certification, communication, traceability, sourcing, quality, yield, lead time, price, warranty, and escalation. - **Build and revision control:** Quantities, lot, date code, substitutions, deviations, approvals, test results, failures, rework, findings, and next revision. ### Use cases - **Prototype PCB build:** Coordinate small-quantity fabrication, component sourcing, assembly, programming, bring-up, inspection, and findings. - **Turnkey PCB assembly:** Manage BOM procurement, approved substitutions, fabrication, stencil, assembly, inspection, programming, test, and logistics. - **Pilot-production preparation:** Improve DFM, panelisation, test, fixtures, programming, traceability, yield, quality, packaging, and revision control. - **Supplier transition:** Qualify a new manufacturer, transfer packages, reconcile capability, run comparison builds, validate quality, and manage continuity. ### Architecture and integration - **One controlled manufacturing release:** Freeze mutually consistent fabrication, assembly, BOM, programming, test, drawing, and revision files for each build. - **No substitution without impact review:** Require approval for electrical, package, footprint, firmware, thermal, quality, certification, test, and lifecycle implications. - **Prototype findings feed the design:** Record defects, yield, rework, measurements, test, assembly, supplier feedback, and bring-up evidence against the revision. ### Quality and control - **Requirement-led selection:** Products and vendors are compared against explicit technical, commercial, security, support, availability, and lifecycle criteria. - **Total lifecycle view:** Purchase price is evaluated with integration, operation, licences, logistics, maintenance, replacement, and exit costs. - **Traceable sourcing:** Specifications, alternatives, vendor evidence, assumptions, approvals, quality checks, and supply risks are documented. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - PCB fabrication, assembly, BOM, programming, test, quantity, and quality requirements - Manufacturing-package completeness and DFM review - Fabricator, assembler, sourcing, capability, lead-time, and cost comparison - BOM procurement, alternate, approval, traceability, and risk coordination - Prototype or pilot build, inspection, programming, testing, and logistics support - Build record, deviations, findings, yield, quality, revision, and supplier documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Can Rokad order fully assembled PCBs?** Yes. We can coordinate turnkey or consigned-component builds including fabrication, BOM, stencil, assembly, inspection, programming, testing, packaging, and logistics. - **Can manufacturers substitute unavailable parts?** Only through an approved process. Alternatives require documented electrical, physical, firmware, thermal, quality, certification, and lifecycle review. - **Does Rokad perform PCB testing?** We can coordinate fabrication electrical tests, AOI, X-ray, programming, functional tests, fixtures, bring-up, inspection, and acceptance criteria according to scope. - **Can Rokad support larger production volumes?** Yes, subject to design maturity, supplier capability, quality systems, forecast, component supply, test coverage, commercial structure, logistics, and production controls. --- ## [Service] Technology consulting and research Canonical URL: https://rokad.co/en/services/technology-consulting-and-research > Evidence-led advisory connecting technology decisions with product, operations, economics, markets, and execution. Rokad supports technology strategy, architecture reviews, AI adoption, technical due diligence, feasibility, transformation planning, vendor evaluation, product discovery, and technology-focused market research. Recommendations are designed to lead to accountable decisions and executable next steps. ### Capabilities - Technology strategy and transformation roadmaps - Software, cloud, security, data, and AI architecture reviews - Technical due diligence and risk assessment - Product, solution, and programme feasibility - Build-versus-buy and vendor evaluation - Technology market, competitor, and ecosystem research ### Challenges - **A high-stakes decision lacks evidence:** Create a structured view of options, constraints, economics, risks, dependencies, and likely outcomes. - **Technology activity lacks a coherent direction:** Align architecture, product, operations, investment, procurement, security, and delivery priorities. - **A proposal or asset requires independent review:** Evaluate technical claims, code, architecture, teams, vendors, scalability, security, and execution risk. ### Service scope - **Evidence gathering:** Interviews, system review, data, documentation, market research, vendor material, code, architecture, and operational evidence. - **Analysis and decision structure:** Options, trade-offs, economics, risks, dependencies, target state, principles, and prioritisation. - **Execution planning:** Workstreams, sequence, ownership, governance, budget ranges, milestones, controls, and immediate next actions. ### Use cases - **Define a technology roadmap:** Connect business priorities with architecture, delivery, operating model, investment, and sequencing. - **Evaluate an acquisition or investment:** Assess product, code, architecture, team, security, scalability, dependencies, and technical risk. - **Plan AI adoption:** Identify valuable use cases, evidence requirements, controls, platform choices, operating implications, and delivery priorities. - **Research a technology market:** Understand vendors, competitors, capabilities, economics, adoption, constraints, and strategic opportunity. ### Delivery process - **Discover:** Clarify the business objective, users, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the system boundaries, delivery plan, integrations, security controls, and operating model before implementation. - **Build and validate:** Deliver in controlled increments with review, automated testing, documentation, and stakeholder validation. - **Deploy and improve:** Launch safely, establish observability and support, then improve the system using operational evidence. ### Engineering standards - **Security by design:** Threats, permissions, secrets, data boundaries, dependencies, and recovery requirements are addressed during architecture and delivery. - **Production quality:** Testing, code review, observability, deployment controls, documentation, and rollback planning are treated as delivery requirements. - **Long-term ownership:** The client receives maintainable source code, operating knowledge, technical documentation, and a practical path for future development. ### Deliverables - Current-state and evidence assessment - Architecture, risk, or due-diligence report - Target direction and decision principles - Market, vendor, or feasibility research - Prioritised roadmap and implementation plan - Executive decision memo and stakeholder briefing ### Engagement models - **Fixed-scope delivery:** A defined outcome, scope, acceptance criteria, milestones, and commercial structure for a bounded project. - **Dedicated product team:** A stable cross-functional team delivering an evolving roadmap with shared product and engineering ownership. - **Embedded engineering:** Specialist engineers working inside an existing product, technology, or operations team. - **Managed evolution:** Ongoing maintenance, reliability, security, feature delivery, and roadmap execution after launch. ### Frequently asked questions - **Will the engagement include an execution plan?** Yes. Recommendations are translated into priorities, dependencies, ownership, budget considerations, risks, governance, and practical next actions. - **Can Rokad provide an independent technical review?** Yes. We can review proposed systems, vendors, codebases, architectures, products, operating models, or investment targets against defined criteria. - **Can consulting continue into implementation?** Yes. Rokad can remain as an advisor, lead the programme, provide an embedded team, or execute development, procurement, and managed operations. --- ## [Service specialisation] Product discovery services Canonical URL: https://rokad.co/en/services/technology-consulting-and-research/product-discovery > Rokad runs structured product discovery to turn an opportunity or requirement into validated users, workflows, scope, architecture, risks, and an executable delivery direction. Product discovery reduces the risk of building the wrong system or solving the right problem poorly. Rokad combines stakeholder research, user workflows, evidence, market and solution review, technical feasibility, service design, product scope, economics, and delivery planning. ### Designed for - **Founders preparing a complex technology product:** Clarify the customer, problem, product boundary, differentiation, operating model, and credible first release. - **Enterprises digitising a business process:** Understand users, current work, exceptions, controls, integrations, data, and organisational change before selecting or building software. - **Teams inheriting an unclear roadmap:** Reframe requests around outcomes, evidence, dependencies, risk, sequencing, and measurable product decisions. ### Challenges - **The solution has been chosen before the problem is understood:** Technology, features, or vendors drive the programme without evidence about users, workflows, constraints, or value. - **Stakeholders describe incompatible requirements:** Different teams optimise for local goals, terminology, exceptions, controls, and success measures without a shared model. - **The first release contains too much uncertainty:** Scope combines product, technical, operational, commercial, data, and adoption risks that cannot all be validated at once. ### Capabilities - Stakeholder, user, operator, buyer, and subject-matter interviews - Current-state workflow, journey, service, data, system, and exception mapping - Problem framing, opportunity, hypotheses, evidence, and success criteria - Market, competitor, alternative, build-versus-buy, and vendor research - Product concepts, user flows, information architecture, and prototype direction - Technical feasibility, architecture options, integrations, data, security, and risk - MVP or first-release scope, roadmap, operating model, economics, and delivery plan ### Solution components - **Problem evidence:** Users, jobs, context, frequency, severity, current alternatives, constraints, incentives, and measurable outcomes. - **Product model:** Actors, workflows, value exchange, capabilities, states, exceptions, permissions, data, and service boundaries. - **Feasibility and economics:** Architecture, vendors, integrations, data, AI, security, operations, delivery effort, commercial model, and total cost. - **Delivery decision:** First release, assumptions, experiments, milestones, dependencies, acceptance criteria, owners, and next-stage plan. ### Use cases - **New SaaS or digital product discovery:** Define customer, workflow, differentiation, product boundary, platform requirements, commercial model, and first release. - **Enterprise process digitisation:** Map current operations, exceptions, data, controls, systems, users, and target service before implementation. - **AI product discovery:** Evaluate task suitability, evidence, model behaviour, data, human control, economics, evaluation, and workflow integration. - **Product reset or roadmap recovery:** Reassess a stalled or overbuilt product against users, outcomes, evidence, architecture, operations, and commercial priorities. ### Architecture and integration - **Outcome before feature:** Tie every proposed capability to a user, workflow, decision, risk, commercial, or operating outcome. - **Assumptions made visible:** Separate verified evidence, stakeholder belief, design choice, technical dependency, and open uncertainty. - **Thin first release:** Select the smallest coherent end-to-end workflow that can validate value and operation without becoming a disposable demo. ### Quality and control - **Evidence-led:** Recommendations distinguish verified facts, assumptions, uncertainty, trade-offs, and evidence gaps. - **Decision-oriented:** Analysis is structured around choices, consequences, priorities, ownership, timing, and practical next actions. - **Independent and executable:** Advice is not tied to unnecessary resale and is translated into architecture, workstreams, controls, and delivery plans. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Discovery brief, stakeholders, research plan, and decision questions - User, workflow, service, system, data, and problem evidence - Product concepts, capabilities, journeys, scope, and priorities - Technical feasibility, architecture options, vendors, and risk assessment - First-release definition, acceptance criteria, and product roadmap - Decision memo, delivery plan, ownership, budget inputs, and next actions ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **How long should product discovery take?** Duration depends on stakeholder count, user access, domain complexity, evidence, integrations, regulatory needs, and decision scope. Discovery should be time-boxed around the decisions required. - **Will discovery include design?** It can include information architecture, user flows, service blueprints, wireframes, interaction concepts, or prototypes where they are needed to test understanding. - **Does discovery guarantee the product should be built?** No. A valuable outcome may be to narrow, change, buy, partner, postpone, or stop the initiative based on evidence and economics. - **Can Rokad continue into implementation?** Yes. Rokad can translate discovery into architecture, design, software, AI, hardware, procurement, launch, and managed operation. --- ## [Service specialisation] Software architecture consulting Canonical URL: https://rokad.co/en/services/technology-consulting-and-research/software-architecture > Rokad provides independent software architecture consulting across applications, platforms, cloud, data, integrations, security, reliability, and modernisation. Architecture consulting connects business requirements, quality attributes, system boundaries, data, teams, operations, and change. Rokad assesses current systems, identifies material risks, compares options, defines target architecture, and translates decisions into an executable migration or delivery plan. ### Designed for - **Teams making high-impact architecture decisions:** Evaluate platform, service, data, cloud, integration, build-versus-buy, and technology choices before commitment. - **Organisations modernising complex systems:** Define safe boundaries, coexistence, data ownership, interfaces, sequencing, and operational transition. - **Leaders requiring independent technical review:** Assess whether a proposal or current architecture can meet security, reliability, scale, delivery, and ownership requirements. ### Challenges - **Architecture debates are framed as technology preferences:** Options are not compared against quality attributes, team capability, change, risk, economics, and operations. - **The target state ignores migration reality:** New diagrams omit existing data, users, integrations, releases, contracts, dependencies, and transitional ownership. - **Architecture is undocumented or no longer accurate:** Teams rely on tribal knowledge and cannot assess impact, ownership, failure, security, or change confidently. ### Capabilities - Current-state application, data, cloud, integration, security, and operational assessment - Business drivers, quality attributes, constraints, scenarios, and architecture principles - Domain, service, module, data, API, event, workflow, and system boundary design - Cloud, platform, deployment, environment, observability, reliability, and recovery architecture - Identity, permissions, secrets, trust boundaries, threat, and security architecture - Build-versus-buy, technology, vendor, pattern, and trade-off evaluation - Target architecture, transition states, decision records, roadmap, and governance ### Solution components - **Architecture drivers:** Outcomes, users, quality attributes, constraints, risks, economics, team structure, and expected change. - **System structure:** Domains, components, services, data, interfaces, events, dependencies, deployment, and ownership boundaries. - **Operational architecture:** Security, reliability, observability, capacity, backup, recovery, environments, release, support, and cost. - **Decision and transition:** Options, trade-offs, records, principles, target state, coexistence, sequence, governance, and validation. ### Use cases - **New platform architecture:** Define product, service, data, identity, integration, deployment, reliability, and operating foundations before build. - **Legacy modernisation architecture:** Identify stable boundaries, migration patterns, coexistence, APIs, data movement, decommissioning, and risk controls. - **Architecture health review:** Assess maintainability, coupling, security, reliability, performance, data, deployment, ownership, and technical debt. - **Vendor or proposal review:** Test solution claims, assumptions, integrations, lock-in, scale, security, operations, delivery, and total lifecycle cost. ### Architecture and integration - **Quality attributes drive structure:** Availability, latency, security, changeability, audit, scale, cost, and recovery are expressed as scenarios and trade-offs. - **Architecture follows ownership:** System boundaries should align with business capability, data authority, team responsibility, and independent change where possible. - **Transition architecture is first-class:** Document coexistence, adapters, migrations, routing, compatibility, data ownership, rollback, and temporary controls. ### Quality and control - **Evidence-led:** Recommendations distinguish verified facts, assumptions, uncertainty, trade-offs, and evidence gaps. - **Decision-oriented:** Analysis is structured around choices, consequences, priorities, ownership, timing, and practical next actions. - **Independent and executable:** Advice is not tied to unnecessary resale and is translated into architecture, workstreams, controls, and delivery plans. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Architecture scope, drivers, stakeholders, evidence, and quality-attribute scenarios - Current-state system, data, integration, deployment, and risk views - Options, trade-offs, build-versus-buy, and technology assessment - Target application, data, cloud, security, and operating architecture - Architecture decision records, principles, standards, and governance - Transition states, migration roadmap, validation, and implementation plan ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Can Rokad review architecture without rewriting the system?** Yes. The result may recommend stabilisation, modular improvements, selective replacement, operational controls, or no major restructuring where evidence supports it. - **Will the engagement recommend specific technologies?** Where needed, yes. Recommendations are tied to requirements, constraints, team capability, ecosystem, risk, cost, support, and migration rather than preference alone. - **Can you review a vendor's architecture proposal?** Yes. We can evaluate assumptions, requirements coverage, boundaries, integrations, security, scale, reliability, lock-in, operations, delivery, and commercial dependencies. - **Can Rokad help implement the target architecture?** Yes. We can lead the programme, deliver selected workstreams, provide embedded architects, or build and operate the complete system. --- ## [Service specialisation] Technology roadmap consulting Canonical URL: https://rokad.co/en/services/technology-consulting-and-research/technology-roadmap > Rokad develops executable technology roadmaps connecting business priorities with architecture, products, platforms, data, security, teams, vendors, and investment. A technology roadmap should explain what changes, why, in what sequence, under whose ownership, with which dependencies, risks, and decision gates. Rokad turns fragmented projects and technical debt into a prioritised transformation system grounded in evidence and operating reality. ### Designed for - **Leadership teams aligning technology investment:** Connect business growth, efficiency, risk, product, customer, data, and operational priorities to a coherent technology sequence. - **Organisations managing technology sprawl:** Rationalise applications, vendors, infrastructure, data, integrations, skills, contracts, and duplicated initiatives. - **Companies preparing a transformation programme:** Define target states, workstreams, transition dependencies, governance, milestones, capabilities, and investment cases. ### Challenges - **The roadmap is a feature list without dependencies:** Initiatives ignore architecture, data, integration, people, procurement, security, migration, operations, and change readiness. - **Technical debt competes invisibly with business work:** Reliability, security, support, lifecycle, architecture, and platform constraints are not translated into business impact and priority. - **Every department has a separate technology plan:** Investments overlap or conflict because shared systems, data, identity, vendors, platforms, and governance are not coordinated. ### Capabilities - Business strategy, outcomes, operating model, risk, and investment alignment - Application, product, data, cloud, infrastructure, security, vendor, and capability landscape - Current-state maturity, lifecycle, technical debt, cost, ownership, and dependency assessment - Target-state architecture, platforms, data, integration, security, and operating principles - Initiative definition, prioritisation, sequencing, dependencies, decision gates, and benefits - Team, skill, partner, procurement, governance, budget, and change requirements - Quarterly, annual, and multi-year roadmap views, metrics, reviews, and adaptation ### Solution components - **Strategic drivers:** Growth, customers, product, efficiency, resilience, risk, compliance, data, market, cost, and organisational change. - **Technology landscape:** Systems, services, data, infrastructure, vendors, contracts, teams, dependencies, lifecycle, costs, and pain points. - **Target capabilities:** Future products, platforms, architecture, information, security, operations, teams, governance, and supplier model. - **Execution portfolio:** Initiatives, sequence, dependencies, owners, investment, benefits, risk, milestones, decision gates, and measures. ### Use cases - **Digital transformation roadmap:** Coordinate customer, operations, software, data, cloud, security, integration, and organisational change. - **Product and platform roadmap:** Balance customer capabilities with architecture, reliability, data, developer platform, security, and lifecycle work. - **Post-acquisition technology plan:** Prioritise continuity, risk, integration, consolidation, platform, data, team, vendor, and value-creation initiatives. - **Technology cost and vendor rationalisation:** Reduce duplicate systems, unmanaged contracts, inefficient platforms, operational burden, and strategic lock-in. ### Architecture and integration - **Capabilities before projects:** Define the organisational and technical ability required, then choose the initiatives that create it. - **Dependencies shape sequence:** Make data, identity, integration, platform, procurement, skill, migration, and policy prerequisites visible. - **Roadmap as a living decision system:** Review outcomes, evidence, risk, capacity, market, incidents, and assumptions regularly rather than freezing a static plan. ### Quality and control - **Evidence-led:** Recommendations distinguish verified facts, assumptions, uncertainty, trade-offs, and evidence gaps. - **Decision-oriented:** Analysis is structured around choices, consequences, priorities, ownership, timing, and practical next actions. - **Independent and executable:** Advice is not tied to unnecessary resale and is translated into architecture, workstreams, controls, and delivery plans. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Strategy, stakeholder, outcome, risk, and investment alignment - Technology landscape, dependency, lifecycle, cost, and maturity assessment - Target capabilities, architecture, operating model, and principles - Prioritised initiatives, workstreams, sequencing, dependencies, and decision gates - Ownership, team, partner, procurement, governance, and budget inputs - Executive roadmap, delivery views, measures, review cadence, and next actions ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **How detailed should a technology roadmap be?** It should be detailed enough to make priority, sequence, dependency, ownership, investment, risk, and next decisions clear without pretending uncertain future work is fully scoped. - **Can the roadmap include existing projects?** Yes. We evaluate current projects against strategic outcomes, dependencies, risks, capacity, sunk cost, and expected value rather than starting from zero. - **Will Rokad provide budget estimates?** We can provide investment ranges, cost drivers, sequencing assumptions, procurement inputs, and areas requiring deeper discovery or vendor quotation. - **Can Rokad help govern the roadmap after delivery?** Yes. We can support quarterly reviews, architecture governance, portfolio decisions, vendor selection, programme leadership, and execution workstreams. --- ## [Service specialisation] Fractional CTO services Canonical URL: https://rokad.co/en/services/technology-consulting-and-research/fractional-cto > Rokad provides fractional CTO leadership for organisations that need senior technology direction and accountability without a full-time executive appointment. A fractional CTO helps leadership make and execute technology decisions across product, architecture, delivery, teams, vendors, security, operations, budgets, and governance. Rokad provides an evidence-led operating cadence with clear decision rights and practical execution support. ### Designed for - **Growing companies without senior technology leadership:** Establish product and engineering direction, architecture, delivery discipline, hiring, vendors, risk, and executive reporting. - **Non-technical founders and leadership teams:** Gain independent oversight of technical plans, teams, agencies, vendors, budgets, delivery claims, and production risk. - **Organisations navigating a transition:** Provide leadership during restructuring, recruitment, acquisition, modernisation, incident recovery, or a permanent CTO search. ### Challenges - **Technology decisions are made project by project:** Product, architecture, data, cloud, security, vendors, hiring, operations, and budgets lack one accountable direction. - **Leadership cannot independently assess delivery:** Progress, quality, risk, estimates, architecture, team capacity, vendor claims, and production readiness are difficult to verify. - **Senior engineers are overloaded with executive work:** Technical leaders split attention across architecture, management, vendors, planning, incidents, stakeholders, and board communication. ### Capabilities - Technology strategy, product direction, roadmap, investment, and executive alignment - Architecture, data, cloud, AI, security, reliability, and technical governance - Engineering operating model, planning, delivery, quality, metrics, and risk management - Team structure, role definition, hiring, assessment, coaching, and leadership development - Vendor, agency, partner, procurement, contract, and technical-commercial oversight - Incident, continuity, security, compliance, customer assurance, and operational leadership - Board, investor, executive, customer, and stakeholder technology communication ### Solution components - **Executive technology agenda:** Priorities, decisions, risks, investments, outcomes, owners, milestones, and leadership communication. - **Technical governance:** Architecture, security, data, reliability, lifecycle, standards, exceptions, reviews, and decision records. - **Delivery and organisation:** Roadmap, planning, teams, roles, hiring, vendors, quality, metrics, dependencies, capacity, and accountability. - **Operational assurance:** Production, incidents, security, continuity, cost, support, service levels, evidence, and stakeholder confidence. ### Use cases - **Startup technology leadership:** Guide product, architecture, engineering team, vendors, delivery, security, cloud, and fundraising diligence. - **Agency and vendor oversight:** Validate scope, estimates, architecture, quality, delivery, change, security, ownership, and commercial dependencies. - **Technology transformation leadership:** Govern roadmap, architecture, migration, teams, partners, risks, budgets, change, and executive reporting. - **Interim leadership and handover:** Stabilise the function, document decisions, recruit or onboard permanent leadership, and transfer context and governance. ### Architecture and integration - **Explicit decision rights:** Clarify what leadership, product, engineering, security, vendors, and the fractional CTO own, recommend, approve, and escalate. - **Cadence over episodic advice:** Use regular executive, product, architecture, delivery, risk, operational, and roadmap reviews to sustain accountability. - **Leadership connected to evidence:** Use production, delivery, quality, cost, security, customer, team, and vendor evidence rather than status narrative alone. ### Quality and control - **Evidence-led:** Recommendations distinguish verified facts, assumptions, uncertainty, trade-offs, and evidence gaps. - **Decision-oriented:** Analysis is structured around choices, consequences, priorities, ownership, timing, and practical next actions. - **Independent and executable:** Advice is not tied to unnecessary resale and is translated into architecture, workstreams, controls, and delivery plans. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Technology leadership mandate, decision rights, priorities, and cadence - Current-state product, architecture, team, vendor, delivery, and risk assessment - Technology strategy, roadmap, operating model, and governance - Architecture, security, reliability, data, and investment decision support - Hiring, vendor, planning, delivery, metric, and executive-review systems - Board, investor, customer, handover, and leadership documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **How is a fractional CTO different from a consultant?** A fractional CTO participates in continuing leadership, decisions, governance, stakeholder communication, and execution accountability rather than delivering only a bounded recommendation. - **Can Rokad manage developers and vendors?** Yes, where included in the mandate. This can cover planning, reviews, architecture, quality, delivery, hiring, escalation, contracts, and performance oversight. - **Can a fractional CTO help hire a permanent CTO?** Yes. We can define the role, assess candidates, support interviews, prepare context, establish governance, and manage transition and handover. - **Is this suitable for very early startups?** It can be, when architecture, vendor, product, hiring, security, or fundraising decisions require senior oversight. The scope should remain proportionate to the company's stage. --- ## [Service specialisation] Technical due diligence Canonical URL: https://rokad.co/en/services/technology-consulting-and-research/technical-due-diligence > Rokad provides independent technical due diligence for investments, acquisitions, partnerships, enterprise procurement, and internal decision-making. Technical due diligence tests whether the product, technology, team, operations, security, claims, and roadmap support the proposed transaction or commitment. Rokad combines document review, interviews, code and architecture assessment, production evidence, risk analysis, and an actionable post-decision plan. ### Designed for - **Investors and acquirers:** Understand product and technology quality, scalability, security, team dependency, technical debt, risk, and value-creation requirements. - **Companies evaluating strategic technology partners:** Validate vendor, platform, product, integration, security, operating, and commercial claims before dependency. - **Founders preparing for diligence:** Identify evidence gaps, technical risks, ownership, security, architecture, operations, and roadmap questions before external review. ### Challenges - **Demonstration quality masks operating reality:** Product interfaces look credible while code, data, infrastructure, security, deployment, incidents, and support remain weak. - **Technical debt is described without business impact:** Reviewers cannot distinguish routine maintenance from material risk to revenue, scale, security, integration, or delivery. - **The organisation depends on undocumented individuals:** Architecture, production, vendors, credentials, releases, incidents, and roadmap knowledge are concentrated in founders or key engineers. ### Capabilities - Product, customer, roadmap, claims, contracts, ownership, and dependency review - Codebase, architecture, data, APIs, integrations, cloud, and infrastructure assessment - Security, privacy, access, secrets, vulnerabilities, incidents, backup, and recovery review - Scalability, performance, reliability, observability, deployment, and operations assessment - Engineering team, roles, capability, bus factor, process, quality, and delivery review - Open source, third-party, licence, vendor, platform, and intellectual-property dependency review - Risk classification, transaction implications, remediation, integration, and value-creation roadmap ### Solution components - **Claims and product evidence:** Customers, functionality, roadmap, usage, architecture, performance, scale, differentiation, and operating evidence. - **Technical asset review:** Code, data, systems, infrastructure, integrations, dependencies, documentation, tests, deployments, and ownership. - **Organisation and operation:** Team, process, vendors, incidents, security, support, service, continuity, cost, governance, and delivery capacity. - **Decision and post-close plan:** Material risks, conditions, valuation considerations, immediate actions, integration, investment, and value creation. ### Use cases - **Investment diligence:** Assess whether product and technology claims, team, roadmap, security, and scale support the investment thesis. - **Acquisition diligence:** Evaluate technical assets, liabilities, integration, continuity, cost, team, vendors, and post-close priorities. - **Enterprise vendor diligence:** Review product architecture, security, data, operations, support, resilience, dependencies, and roadmap before adoption. - **Diligence readiness:** Help a company organise evidence, identify gaps, remediate material risk, and prepare clear technical explanations. ### Architecture and integration - **Materiality over exhaustive criticism:** Focus on issues that affect transaction thesis, continuity, customers, security, scale, integration, cost, and execution. - **Verify through multiple evidence types:** Compare interviews and documents with source, systems, production telemetry, incidents, customers, dependencies, and operating records. - **Separate present risk from future investment:** Distinguish immediate liabilities, normal technical debt, growth requirements, integration work, and optional value-creation opportunities. ### Quality and control - **Evidence-led:** Recommendations distinguish verified facts, assumptions, uncertainty, trade-offs, and evidence gaps. - **Decision-oriented:** Analysis is structured around choices, consequences, priorities, ownership, timing, and practical next actions. - **Independent and executable:** Advice is not tied to unnecessary resale and is translated into architecture, workstreams, controls, and delivery plans. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Diligence scope, information request, interviews, and evidence plan - Product, code, architecture, data, infrastructure, security, and operations assessment - Team, process, vendor, dependency, licence, ownership, and continuity review - Material risk register with evidence, impact, likelihood, and remediation - Transaction, integration, investment, and value-creation implications - Executive report, technical appendix, briefing, and post-decision roadmap ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Can technical due diligence be completed confidentially?** Yes. Access, data handling, confidentiality, interview, repository, environment, reporting, and retention arrangements are defined before work begins. - **Do you need full source-code access?** Full access provides stronger evidence, but scope can be adapted to transaction stage and available information. Any limitations are stated clearly in conclusions. - **Will the report provide a pass or fail?** We provide evidence, material risks, strengths, uncertainties, implications, and recommended actions so decision-makers can evaluate them against the transaction thesis and terms. - **Can Rokad support post-acquisition execution?** Yes. We can lead immediate risk closure, architecture, integration, roadmap, team, vendor, security, modernisation, and managed operations workstreams. --- ## [Service] Cloud and DevOps Canonical URL: https://rokad.co/en/services/cloud-devops > Cloud and delivery platforms engineered for repeatable releases, resilient operation, security, visibility, and controlled cost. Rokad designs, builds, migrates, and operates cloud platforms across infrastructure, networking, identity, deployment, containers, Kubernetes, observability, security, backup, recovery, and developer enablement. The objective is not infrastructure for its own sake, but a dependable operating system for software and teams. ### Capabilities - Cloud strategy, landing zones, architecture, and migration - Platform engineering and developer self-service - CI/CD, release automation, environments, and infrastructure as code - Containers, Kubernetes, service networking, and workload operations - DevSecOps, identity, secrets, policy, vulnerability, and supply-chain controls - Reliability, observability, incident response, backup, recovery, and cost optimisation ### Challenges - **Infrastructure changes are manual and risky:** Environments drift, releases depend on individuals, and recovery procedures are undocumented or untested. - **Cloud growth increases cost without improving reliability:** Teams add services and capacity without clear ownership, measurement, architecture standards, or financial controls. - **Developers wait on operational bottlenecks:** Provisioning, access, deployments, diagnostics, and production changes require repeated manual coordination. ### Service scope - **Assessment and target platform:** Review architecture, workloads, delivery, security, reliability, cost, skills, and operational constraints before defining the target state. - **Platform implementation:** Build cloud foundations, networks, identity, infrastructure code, pipelines, observability, policy, backup, and service interfaces. - **Migration and operation:** Move workloads safely, validate service objectives, establish runbooks and ownership, and continuously improve the platform. ### Use cases - **Migrate production workloads to cloud:** Move applications and data through assessed waves with landing zones, controls, rehearsals, and rollback planning. - **Build an internal developer platform:** Standardise environments, services, deployments, observability, access, and golden paths through self-service interfaces. - **Stabilise release and infrastructure operations:** Replace manual deployments and inconsistent environments with automation, testing, telemetry, and controlled change. - **Improve reliability and cloud economics:** Connect service objectives, capacity, incidents, architecture, utilisation, commitments, and ownership to cost outcomes. ### Delivery process - **Discover:** Clarify objectives, users, systems, data, constraints, dependencies, risk, and measurable acceptance criteria. - **Architect:** Define the target system, operating model, security controls, migration sequence, and ownership before implementation. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish production ownership, service controls, measurement, support, and a continuous improvement backlog. ### Engineering standards - **Secure by design:** Identity, permissions, secrets, networks, data boundaries, dependencies, change controls, and recovery are addressed throughout delivery. - **Observable operation:** Metrics, logs, traces, data quality, costs, failures, capacity, and service outcomes are made visible and actionable. - **Automated and reproducible:** Infrastructure, pipelines, configuration, tests, deployment, and recovery procedures are versioned and repeatable wherever practical. ### Deliverables - Cloud and DevOps current-state assessment - Target platform architecture and decision records - Infrastructure-as-code repositories and environment configuration - CI/CD, release, approval, and rollback workflows - Identity, security, observability, backup, and recovery controls - Migration, cutover, runbook, service, and operating documentation ### Engagement models - **Assessment and roadmap:** A bounded current-state review, target architecture, prioritised risks, and executable transformation plan. - **Fixed-scope implementation:** A defined platform, migration, pipeline, or reliability outcome with explicit milestones and acceptance criteria. - **Embedded platform team:** Specialists working with internal engineering, data, security, and operations teams over an evolving roadmap. - **Managed operation:** Ongoing ownership of production infrastructure, data platforms, reliability, security, cost, and improvement. ### Frequently asked questions - **Can Rokad work across more than one cloud provider?** Yes. We can design single-cloud, multi-cloud, hybrid, and provider-neutral operating patterns where the business, regulatory, availability, or commercial requirements justify the complexity. - **Do you use infrastructure as code?** Yes, wherever practical. Infrastructure, policy, configuration, environments, and deployment workflows are versioned, reviewed, tested, and reproducible. - **Can you take over an existing cloud environment?** Yes. We begin with access, architecture, inventory, security, cost, deployment, observability, backup, recovery, and ownership assessment before controlled handover. - **Do you provide ongoing cloud and DevOps management?** Yes. Managed services can cover infrastructure, deployments, monitoring, incidents, security, backup, cost, upgrades, capacity, and service reporting. --- ## [Service specialisation] Cloud platform engineering Canonical URL: https://rokad.co/en/services/cloud-devops/cloud-platforms > Rokad designs, builds, migrates, secures, and operates production cloud platforms across AWS, Microsoft Azure, Google Cloud, and Cloudflare. A cloud provider supplies capabilities, but a dependable cloud platform requires deliberate account structure, identity, networking, policy, security, infrastructure code, delivery, observability, backup, recovery, cost controls, and accountable operations. Rokad selects and engineers the provider architecture around workload requirements rather than reproducing a generic reference stack. ### Designed for - **Product teams building cloud-native software:** Establish secure environments, networking, compute, data, delivery, observability, resilience, and cost ownership before production scale. - **Organisations standardising fragmented cloud estates:** Bring independently created accounts, subscriptions, projects, applications, identities, policies, and operating practices under a governed platform model. - **Companies evaluating provider or multi-cloud choices:** Compare workload fit, service maturity, data, regions, skills, contracts, costs, portability, and exit requirements before commitment. ### Challenges - **The provider account became the architecture:** Resources were created directly without durable boundaries for environments, teams, workloads, identity, networks, policy, telemetry, or ownership. - **Cloud services grow faster than operational control:** Permissions, secrets, logs, backups, upgrades, dependencies, quotas, incidents, vulnerabilities, and cost lack one operating model. - **Multi-cloud is declared without a workload reason:** Teams duplicate platforms and skills without defining which workloads genuinely require another provider or how cross-cloud operation will work. ### Capabilities - Cloud-provider and workload-fit assessment, architecture, roadmap, and migration planning - AWS, Microsoft Azure, Google Cloud, and Cloudflare platform engineering - Landing zones, organisations, accounts, subscriptions, projects, environments, and resource hierarchy - Identity, networking, DNS, private connectivity, encryption, secrets, policy, logging, and security foundations - Compute, containers, serverless, storage, databases, messaging, edge, data, and application services - Infrastructure as code, CI/CD, policy as code, observability, backup, recovery, and operational automation - Reliability, capacity, performance, cost, governance, documentation, and managed cloud operation ### Solution components - **Cloud foundation:** Organisation, accounts, subscriptions, projects, regions, networks, identity, policy, logging, security, tagging, budgets, and shared services. - **Workload platform:** Compute, containers, serverless, data, storage, messaging, edge, integration, scaling, resilience, and service contracts. - **Delivery and control plane:** Infrastructure code, pipelines, artefacts, secrets, environments, policy, approvals, change evidence, and rollback. - **Cloud operations:** Telemetry, service objectives, incidents, backups, recovery, vulnerabilities, upgrades, capacity, cost, support, and lifecycle. ### Use cases - **Production cloud foundation:** Create governed account, identity, network, security, delivery, observability, backup, and cost foundations for new workloads. - **Cloud-native application platform:** Run web, API, worker, event, data, AI, and container workloads on supported provider services with clear operating ownership. - **Cloud estate modernisation:** Refactor unmanaged infrastructure, permissions, networking, deployment, telemetry, security, recovery, and cost into a controlled platform. - **Provider and architecture decision:** Evaluate AWS, Azure, Google Cloud, Cloudflare, or a deliberate combination against product, data, compliance, region, skill, and economic requirements. ### Architecture and integration - **Provider-native where it creates durable value:** Use managed capabilities when they materially improve reliability, security, delivery, or operations while documenting dependencies and exit implications. - **Environment and ownership boundaries first:** Define account, subscription, project, network, identity, data, budget, and support boundaries before individual services are deployed. - **Infrastructure and policy are versioned:** Create reproducible resources, permissions, network rules, monitoring, backups, and controls through reviewed automated delivery. ### Quality and control - **Secure by design:** Identity, permissions, secrets, data boundaries, dependencies, change controls, and recovery are addressed throughout delivery. - **Observable operation:** Metrics, logs, traces, quality, cost, failures, and service outcomes are made visible and actionable. - **Reproducible delivery:** Configuration, tests, infrastructure, pipelines, artefacts, changes, and recovery procedures are versioned and repeatable. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Cloud workload, provider, service, data, security, cost, and operating assessment - Target cloud foundation, workload, integration, reliability, and governance architecture - Landing-zone and shared-service infrastructure as code - Application, container, serverless, data, network, identity, and security implementation - CI/CD, policy, observability, backup, recovery, cost, and incident controls - Architecture decisions, runbooks, ownership, support, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Which cloud provider should we use?** The decision depends on workload architecture, regions, data, AI and platform services, compliance, existing identity and contracts, team skills, support, total cost, and exit requirements. Rokad evaluates these against actual workloads. - **Can Rokad work across more than one cloud?** Yes, where business continuity, customer requirements, acquisitions, data, edge delivery, or specialised services justify it. We avoid duplicating every capability without a workload-specific reason. - **Can Rokad take over an existing cloud environment?** Yes. We audit accounts, identity, networks, resources, code, deployments, telemetry, security, backups, cost, documentation, incidents, and ownership before stabilisation and transition. - **Can Rokad operate the cloud platform after delivery?** Yes. Managed services can cover releases, incidents, monitoring, security, backups, recovery, upgrades, cost, capacity, compliance evidence, and continuous platform improvement. --- ## [Platform service] AWS cloud engineering services Canonical URL: https://rokad.co/en/services/cloud-devops/cloud-platforms/aws Platform: Amazon Web Services > Rokad designs, builds, migrates, secures, and operates production AWS environments across accounts, networking, compute, containers, serverless, data, delivery, and reliability. AWS offers broad infrastructure and managed services, but a production estate needs a deliberate multi-account foundation, identity, networking, guardrails, infrastructure code, workload architecture, telemetry, backup, recovery, cost ownership, and operational support. Rokad engineers these layers around each workload rather than creating an ungoverned service collection. ### Designed for - **Product teams launching production workloads on AWS:** Establish accounts, networks, identity, environments, delivery, observability, backup, recovery, and cost controls before scale. - **Organisations migrating applications and data to AWS:** Assess dependencies, establish a landing zone, move workloads in waves, validate service objectives, and retire legacy infrastructure safely. - **Enterprises rationalising an existing AWS estate:** Standardise accounts, permissions, networking, infrastructure code, security, telemetry, tagging, support, and FinOps practices. ### Implementation risks - **AWS accounts and resources grew without a durable hierarchy:** Workloads, environments, identities, networks, logs, budgets, and ownership are mixed in ways that increase risk and operating effort. - **Managed services are adopted without lifecycle ownership:** Upgrades, quotas, scaling, data retention, backup, security, observability, dependencies, and cost are not assigned to accountable teams. - **Permissions and network access are broader than the workload requires:** Long-lived keys, shared roles, permissive security groups, public endpoints, and inconsistent resource policies weaken assurance. ### Platform capabilities - AWS Organizations, Control Tower, account vending, organisational units, shared services, and landing-zone architecture - IAM Identity Center, workload roles, federation, least privilege, secrets, KMS, policy, CloudTrail, and Config - VPC, subnets, routing, Transit Gateway, PrivateLink, Route 53, load balancing, CloudFront, and hybrid connectivity - EC2, Auto Scaling, ECS, EKS, Lambda, API Gateway, event-driven, and serverless application architecture - S3, RDS, Aurora, DynamoDB, ElastiCache, OpenSearch, messaging, data movement, backup, and recovery - CloudFormation, CDK, Terraform, CI/CD, artefacts, deployment strategies, observability, and operational automation - Security Hub, GuardDuty, WAF, vulnerability, incident, capacity, performance, cost, and managed AWS operation ### Implementation system - **AWS landing zone:** Organisation, accounts, identity, regions, networks, logging, security, policy, tagging, budgets, and shared platform services. - **Workload architecture:** Compute, containers, serverless, storage, databases, events, APIs, caching, scaling, failure domains, and data boundaries. - **Delivery system:** Infrastructure code, pipelines, artefacts, configuration, secrets, environments, approvals, progressive delivery, and rollback. - **AWS operations:** Telemetry, service objectives, incidents, backup, recovery, security findings, quotas, capacity, cost, support, and lifecycle. ### Use cases - **AWS landing-zone implementation:** Create a secure multi-account foundation with central identity, networking, logging, guardrails, budgets, and repeatable account provisioning. - **Application and database migration:** Move services and data through assessed migration patterns, rehearsals, replication, cutover, validation, rollback, and operational transition. - **AWS cloud-native platform:** Build container, serverless, event, API, data, AI, and web workloads on governed managed services with clear ownership. - **AWS reliability and cost improvement:** Connect architecture, utilisation, commitments, storage, data transfer, scaling, incidents, and service objectives to measurable outcomes. ### Architecture - **Multi-account boundaries follow risk and ownership:** Separate production, non-production, security, logging, shared services, data, and business domains according to isolation and operating needs. - **Workload identity replaces embedded credentials:** Use federated users, roles, service identities, short-lived credentials, scoped policies, and auditable assumption paths. - **Managed services are selected with exit and recovery in view:** Document data portability, backup, restoration, service quotas, region dependencies, failure behaviour, and replacement cost. ### Quality and governance - **Secure cloud boundaries:** Accounts, subscriptions, projects, identity, networks, secrets, encryption, policy, logs, and production access are designed as explicit trust boundaries. - **Reproducible infrastructure:** Infrastructure, configuration, policy, deployment, monitoring, backup, and recovery controls are versioned and delivered through reviewable automation. - **Operated reliability and cost:** Service objectives, telemetry, incidents, capacity, recovery, usage, commitments, budgets, and ownership are measured together. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - AWS account, workload, network, identity, security, data, cost, and migration assessment - Landing-zone, workload, data, integration, reliability, and governance architecture - AWS infrastructure-as-code repositories, account foundations, and shared services - Compute, container, serverless, network, storage, database, and event implementation - CI/CD, monitoring, security, backup, recovery, cost, and incident controls - Architecture decisions, runbooks, ownership, support, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad build an AWS landing zone for an existing organisation?** Yes. We assess current accounts, organisations, identity, networking, logs, policies, workloads, contracts, and operating constraints before establishing or modernising the landing zone. - **Can Rokad migrate workloads from another cloud or on-premises environment?** Yes. We assess dependencies, data, service equivalence, networking, identity, cutover, rollback, operations, cost, and provider-specific constraints before migration. - **Does Rokad use infrastructure as code on AWS?** Yes. We use suitable tools such as CloudFormation, CDK, or Terraform to version infrastructure, policy, environments, and repeatable operational controls. - **Can Rokad manage AWS after launch?** Yes. Managed services can cover releases, monitoring, incidents, security findings, backups, recovery, upgrades, quotas, capacity, cost, and platform evolution. --- ## [Platform service] Microsoft Azure cloud engineering services Canonical URL: https://rokad.co/en/services/cloud-devops/cloud-platforms/microsoft-azure Platform: Microsoft Azure > Rokad designs, builds, migrates, secures, and operates Microsoft Azure environments across landing zones, identity, networking, applications, data, delivery, and reliability. Azure is strongest when cloud architecture is integrated with Microsoft Entra, Microsoft 365, Power Platform, data, security, and enterprise operations. Rokad structures management groups, subscriptions, identity, networks, policy, workload platforms, observability, recovery, cost, and deployment around the organisation's operating model. ### Designed for - **Microsoft-centred enterprises adopting Azure:** Connect cloud workloads with Entra identity, Microsoft 365, Dynamics, Power Platform, data, security, and established enterprise controls. - **Teams migrating Windows, .NET, data, or mixed workloads:** Select appropriate virtual machine, application, container, database, integration, and modernisation patterns with controlled cutover. - **Organisations standardising existing Azure subscriptions:** Improve management groups, policy, networks, identity, Defender, monitoring, deployment, backup, cost, and platform ownership. ### Implementation risks - **Subscriptions were created before governance boundaries:** Environments, departments, applications, policies, budgets, networks, data, and support responsibilities overlap. - **Entra and Azure permissions evolved independently:** Directory roles, Azure RBAC, managed identities, applications, groups, guests, secrets, and conditional access create excessive privilege. - **Azure services are connected without a clear operational model:** App services, functions, AKS, data, integration, private endpoints, monitoring, Defender, and backup have fragmented ownership. ### Platform capabilities - Azure landing zones, management groups, subscriptions, resource groups, policy, tagging, budgets, and shared services - Microsoft Entra ID, managed identities, workload identity, RBAC, Key Vault, conditional access, logging, and governance - Virtual networks, hub-spoke, Virtual WAN, private endpoints, DNS, load balancing, Front Door, and hybrid connectivity - Virtual Machines, App Service, Functions, Container Apps, AKS, API Management, Logic Apps, and event-driven architecture - Storage, Azure SQL, PostgreSQL, Cosmos DB, Service Bus, Event Grid, data platforms, backup, and recovery - Bicep, ARM, Terraform, GitHub Actions, Azure DevOps, deployment slots, environments, approvals, and rollback - Azure Monitor, Application Insights, Defender for Cloud, Sentinel integration, reliability, cost, and managed operation ### Implementation system - **Azure landing zone:** Tenant, management groups, subscriptions, identity, policy, network, logging, security, budgets, and shared platform services. - **Application and data platform:** Compute, containers, serverless, APIs, integration, storage, databases, events, scale, availability, and data boundaries. - **Azure delivery system:** Bicep or Terraform, pipelines, artefacts, managed identities, environments, approvals, deployment strategies, and recovery. - **Cloud operations:** Monitor, Application Insights, Defender, alerts, objectives, incidents, backup, cost, capacity, support, and service lifecycle. ### Use cases - **Azure enterprise landing zone:** Establish management, subscription, network, identity, policy, security, logging, budget, and account-provisioning foundations. - **Microsoft workload migration:** Move .NET, Windows, SQL, identity, file, integration, and business applications with assessed rehost, replatform, and refactor paths. - **Azure application modernisation:** Adopt managed application, container, serverless, API, data, messaging, and observability services where they reduce operating risk. - **Azure governance and reliability programme:** Standardise policy, permissions, network, security, deployment, monitoring, backup, recovery, cost, and support across subscriptions. ### Architecture - **Management hierarchy follows delegation and policy:** Design tenant, management-group, subscription, resource-group, and resource boundaries around ownership, isolation, compliance, and cost. - **Private connectivity is applied by data and threat model:** Use private endpoints, network segmentation, service endpoints, firewalls, DNS, and controlled egress where workload risk justifies them. - **Managed identities are the default application credential:** Use Entra-backed workload identity and scoped RBAC to reduce static secrets and improve auditability across Azure services. ### Quality and governance - **Secure cloud boundaries:** Accounts, subscriptions, projects, identity, networks, secrets, encryption, policy, logs, and production access are designed as explicit trust boundaries. - **Reproducible infrastructure:** Infrastructure, configuration, policy, deployment, monitoring, backup, and recovery controls are versioned and delivered through reviewable automation. - **Operated reliability and cost:** Service objectives, telemetry, incidents, capacity, recovery, usage, commitments, budgets, and ownership are measured together. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Azure tenant, subscription, workload, network, identity, security, cost, and migration assessment - Landing-zone, application, data, integration, reliability, and governance architecture - Bicep or Terraform repositories, subscription foundations, policy, network, and shared services - Application, container, serverless, API, storage, database, and integration implementation - CI/CD, monitoring, Defender, backup, recovery, cost, and incident controls - Architecture decisions, runbooks, ownership, support, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad design an Azure landing zone around an existing Microsoft tenant?** Yes. We review Entra, management groups, subscriptions, networks, policy, logs, security, workloads, contracts, and ownership before implementation or modernisation. - **Can Rokad migrate Windows and SQL workloads to Azure?** Yes. We assess compatibility, licensing, identity, data, downtime, managed-service options, performance, backup, recovery, and cutover before selecting a migration pattern. - **Can Azure integrate with Microsoft 365, Dynamics, and Power Platform?** Yes. We design identity, API, event, data, workflow, security, and operating boundaries across the Microsoft ecosystem. - **Can Rokad provide managed Azure operations?** Yes. Scope can include deployments, monitoring, incidents, Defender findings, backups, recovery, updates, capacity, cost, identity, and platform improvement. --- ## [Platform service] Google Cloud engineering services Canonical URL: https://rokad.co/en/services/cloud-devops/cloud-platforms/google-cloud Platform: Google Cloud > Rokad designs, builds, migrates, secures, and operates Google Cloud environments across resource hierarchy, networking, applications, containers, data, AI, and reliability. Google Cloud combines strong container, serverless, data, analytics, and AI capabilities with a project-oriented resource model. Rokad designs organisations, folders, projects, identity, networks, policies, application services, data platforms, observability, recovery, cost, and delivery around workload and ownership boundaries. ### Designed for - **Product and data teams building on Google Cloud:** Create governed foundations for Cloud Run, GKE, APIs, event systems, databases, BigQuery, analytics, and AI workloads. - **Organisations migrating applications or analytical estates:** Move services and data with project, network, identity, cutover, validation, recovery, and operational transition controls. - **Companies rationalising project and billing sprawl:** Standardise folders, projects, IAM, networks, service accounts, logging, security, budgets, labels, and support ownership. ### Implementation risks - **Projects were created without a durable organisation model:** Environments, business domains, data, networks, billing, policies, logs, and ownership do not align. - **Service accounts and keys create hidden trust paths:** Broad roles, long-lived keys, cross-project access, unmanaged secrets, and weak workload identity increase exposure. - **Data and application platforms are operated separately:** Cloud Run, GKE, BigQuery, storage, messaging, AI, monitoring, and networking lack a coordinated reliability and cost model. ### Platform capabilities - Google Cloud organisation, folders, projects, billing, policies, labels, shared VPC, and landing-zone architecture - Cloud Identity, IAM, service accounts, Workload Identity Federation, Secret Manager, KMS, audit logs, and policy - VPC, Shared VPC, private service access, Cloud DNS, load balancing, Cloud CDN, Interconnect, and hybrid connectivity - Cloud Run, GKE, Compute Engine, Functions, API Gateway, Apigee, Pub/Sub, and event-driven architecture - Cloud Storage, Cloud SQL, AlloyDB, Spanner, Firestore, BigQuery, data movement, backup, and recovery - Terraform, Cloud Build, GitHub Actions, artefacts, environments, progressive delivery, observability, and automation - Cloud Operations, Security Command Center, vulnerability, incident, capacity, performance, cost, and managed operation ### Implementation system - **Google Cloud foundation:** Organisation, folders, projects, identity, billing, networks, policy, logging, security, budgets, and shared services. - **Application and data platform:** Cloud Run, GKE, compute, APIs, events, storage, databases, BigQuery, AI, scaling, and failure domains. - **Delivery and policy plane:** Terraform, pipelines, artefacts, service identities, environments, approvals, policy, deployment, validation, and rollback. - **Google Cloud operations:** Metrics, logs, traces, objectives, incidents, backup, recovery, security findings, quotas, capacity, cost, and support. ### Use cases - **Google Cloud landing zone:** Create organisation, folder, project, network, identity, logging, policy, security, billing, and account-provisioning foundations. - **Cloud Run and GKE application platform:** Build scalable container and API workloads with managed identity, delivery, events, data, telemetry, and reliability controls. - **Data and analytics foundation:** Integrate storage, BigQuery, streaming, transformation, governance, BI, AI, and workload cost under one cloud architecture. - **Google Cloud migration and modernisation:** Move applications and data while improving service boundaries, networking, deployment, observability, recovery, and operating ownership. ### Architecture - **Project boundaries follow workload and policy ownership:** Separate environments, domains, data, shared services, security, and billing where isolation, delegation, or lifecycle differ. - **Workload Identity Federation reduces key distribution:** Use short-lived identity for CI/CD, applications, and external systems instead of unmanaged service-account keys where supported. - **Serverless and Kubernetes are selected by workload shape:** Choose Cloud Run, GKE, functions, or virtual machines from traffic, runtime, networking, state, portability, and operational requirements. ### Quality and governance - **Secure cloud boundaries:** Accounts, subscriptions, projects, identity, networks, secrets, encryption, policy, logs, and production access are designed as explicit trust boundaries. - **Reproducible infrastructure:** Infrastructure, configuration, policy, deployment, monitoring, backup, and recovery controls are versioned and delivered through reviewable automation. - **Operated reliability and cost:** Service objectives, telemetry, incidents, capacity, recovery, usage, commitments, budgets, and ownership are measured together. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Google Cloud organisation, project, workload, network, identity, data, cost, and migration assessment - Landing-zone, application, data, integration, reliability, and governance architecture - Terraform repositories, resource hierarchy, shared networking, policy, and platform foundations - Cloud Run, GKE, compute, API, event, storage, database, and analytical implementation - CI/CD, Cloud Operations, security, backup, recovery, cost, and incident controls - Architecture decisions, runbooks, ownership, support, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad design a Google Cloud organisation and project structure?** Yes. We map teams, environments, workloads, data, policies, networks, billing, and support into a resource hierarchy with controlled delegation. - **Should our application use Cloud Run or GKE?** The choice depends on runtime control, traffic, networking, state, sidecars, portability, scaling, team capability, and total operating effort. We evaluate the workload before selecting the platform. - **Can Rokad integrate BigQuery and AI services with applications?** Yes. We design identity, data, APIs, events, pipelines, governance, cost, latency, and operational boundaries across application, analytics, and AI workloads. - **Can Rokad operate Google Cloud after launch?** Yes. Managed services can include releases, monitoring, incidents, security, backups, recovery, upgrades, quotas, capacity, cost, and platform evolution. --- ## [Platform service] Cloudflare development and platform services Canonical URL: https://rokad.co/en/services/cloud-devops/cloud-platforms/cloudflare Platform: Cloudflare > Rokad builds and operates Cloudflare application, edge, storage, security, connectivity, and Zero Trust solutions across Workers and the wider developer platform. Cloudflare can serve as an edge delivery, application, security, storage, and connectivity platform. Rokad defines which responsibilities belong at the edge, how state and origin systems interact, how Workers and data services are structured, and how deployments, observability, security, cost, and recovery are operated. ### Designed for - **Teams building globally distributed web and API products:** Use Workers, Pages, routing, caching, storage, queues, and edge controls to reduce latency and simplify delivery where appropriate. - **Organisations modernising delivery and application security:** Integrate DNS, CDN, WAF, bot controls, rate limiting, certificates, origin protection, and application observability. - **Companies implementing Zero Trust access and connectivity:** Connect users, applications, networks, devices, identities, policies, gateways, tunnels, and audit under a controlled model. ### Implementation risks - **Edge logic grows without application boundaries:** Routing, authentication, caching, APIs, data, transforms, security, and origin behaviour become tightly coupled in Workers. - **Distributed state is selected without consistency requirements:** KV, D1, R2, Durable Objects, caches, queues, and origin databases are used without clear authority, latency, durability, or recovery rules. - **Security configuration is separated from application delivery:** WAF, rate limits, bot rules, DNS, certificates, access policy, deployments, logs, and incident response have different owners and release paths. ### Platform capabilities - Cloudflare Workers, Pages, static assets, routing, bindings, service-to-service patterns, and edge application architecture - R2, D1, KV, Durable Objects, Queues, caching, state authority, data lifecycle, backup, and recovery design - DNS, CDN, image and asset delivery, cache rules, redirects, certificates, load balancing, and origin architecture - WAF, DDoS protection, bot controls, rate limiting, API security, origin protection, and security-rule management - Cloudflare Zero Trust, Access, Gateway, Tunnel, device, identity, policy, private applications, and network connectivity - Wrangler, environments, versions, deployments, gradual rollout, secrets, CI/CD, logging, analytics, and operational automation - Performance, reliability, incident response, observability, usage, cost, security, documentation, and managed operation ### Implementation system - **Edge application layer:** Workers, Pages, routes, services, bindings, authentication, APIs, assets, caching, transforms, and origin interaction. - **Distributed data layer:** R2, D1, KV, Durable Objects, queues, caches, origin databases, consistency, retention, replication, and recovery. - **Security and connectivity:** DNS, CDN, WAF, DDoS, bots, rate limits, Zero Trust, tunnels, identity, policies, certificates, and audit. - **Cloudflare operations:** Wrangler, environments, deployments, versions, telemetry, alerts, incidents, usage, cost, rule changes, and support. ### Use cases - **Cloudflare Workers application:** Build web, API, middleware, authentication, routing, scheduled, queue, and integration workloads on the edge runtime. - **Global website and API delivery:** Improve DNS, certificates, caching, asset delivery, origin shielding, routing, performance, observability, and deployment safety. - **Cloudflare security modernisation:** Design WAF, rate limits, bot controls, API protection, origin restrictions, logging, rule lifecycle, testing, and incident workflows. - **Zero Trust application access:** Replace broad network access with identity-aware policies, private tunnels, device context, application segmentation, and audit. ### Architecture - **State service follows consistency and access pattern:** Select R2, D1, KV, Durable Objects, Queues, cache, or an origin database from authority, transaction, latency, durability, and recovery needs. - **The edge and origin share an explicit contract:** Define authentication, headers, caching, retries, timeouts, idempotency, error behaviour, data ownership, and failover between layers. - **Rules and deployments follow one change process:** Version application code, configuration, routes, WAF, rate limits, DNS, access policy, secrets, validation, and rollback where practical. ### Quality and governance - **Secure cloud boundaries:** Accounts, subscriptions, projects, identity, networks, secrets, encryption, policy, logs, and production access are designed as explicit trust boundaries. - **Reproducible infrastructure:** Infrastructure, configuration, policy, deployment, monitoring, backup, and recovery controls are versioned and delivered through reviewable automation. - **Operated reliability and cost:** Service objectives, telemetry, incidents, capacity, recovery, usage, commitments, budgets, and ownership are measured together. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Cloudflare application, domain, origin, security, data, connectivity, usage, and risk assessment - Edge, state, origin, security, Zero Trust, deployment, and operating architecture - Production Workers, Pages, bindings, storage, queue, routing, and integration implementation - DNS, CDN, WAF, rate-limit, bot, certificate, tunnel, access, and origin controls - CI/CD, gradual deployment, observability, logging, backup, recovery, and incident workflows - Architecture decisions, runbooks, rule ownership, support, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad build full applications on Cloudflare Workers?** Yes. We can build web, API, middleware, authentication, scheduled, queue, storage, and integration workloads, while assessing runtime, state, dependency, and portability constraints. - **Which Cloudflare data service should we use?** The choice depends on transaction needs, consistency, access pattern, object size, query model, latency, durability, region, backup, and whether another system remains authoritative. - **Can Rokad configure Cloudflare WAF and Zero Trust?** Yes. We can design rules, rate limits, bots, API controls, tunnels, identity, device, access policy, logs, testing, exceptions, and operational ownership. - **Can Rokad migrate an existing application to Cloudflare?** Yes. We assess runtime compatibility, state, APIs, dependencies, origin systems, data, build and deployment, security, observability, and staged cutover before migration. --- ## [Service specialisation] Cloud migration Canonical URL: https://rokad.co/en/services/cloud-devops/cloud-migration > Rokad plans and executes cloud migrations through workload assessment, target architecture, landing zones, migration waves, validation, cutover, and production handover. A cloud migration changes architecture, operations, security, cost, ownership, and recovery—not only hosting. Rokad assesses applications, data, dependencies, environments, compliance, performance, and organisational readiness before moving workloads through controlled migration waves. ### Designed for - **Organisations leaving ageing or constrained infrastructure:** Move from on-premises, colocation, unsupported hosting, or inflexible environments without losing operational continuity. - **Companies consolidating fragmented cloud estates:** Standardise accounts, networks, identity, security, observability, deployment, cost, and ownership across workloads. - **Product teams preparing for scale or assurance:** Create a production foundation that supports growth, enterprise requirements, recovery, and controlled delivery. ### Challenges - **Dependencies are poorly understood:** Applications, databases, jobs, files, identities, network paths, vendors, and operating procedures create hidden migration risk. - **A lift-and-shift would preserve existing problems:** Moving unchanged workloads can reproduce fragility, manual operations, security gaps, and inefficient cost in cloud form. - **The organisation cannot tolerate prolonged downtime:** Data synchronisation, traffic transition, rollback, user communication, and production validation require explicit planning. ### Capabilities - Application, data, dependency, infrastructure, security, and cost assessment - Cloud strategy, provider evaluation, target architecture, and landing zones - Account, network, identity, policy, logging, and shared-service foundations - Rehost, replatform, refactor, replace, retain, and retire decisions - Migration waves, data movement, rehearsal, cutover, rollback, and validation - Observability, backup, recovery, deployment, and operating-model transition - Post-migration optimisation, decommissioning, documentation, and managed support ### Solution components - **Migration portfolio:** Inventory, criticality, dependencies, target pattern, effort, risk, sequence, ownership, and acceptance for each workload. - **Cloud foundation:** Accounts, networks, identity, policies, secrets, logging, connectivity, shared services, tagging, and financial controls. - **Migration factory:** Repeatable tooling, runbooks, data movement, testing, rehearsals, approvals, cutover, rollback, and evidence. - **Operational transition:** Monitoring, incidents, support, backup, recovery, cost, security, ownership, training, and legacy decommissioning. ### Use cases - **Data-centre exit:** Move applications, databases, storage, networks, and operational responsibility before a facility or contract deadline. - **SaaS platform migration:** Create scalable environments, deployment automation, observability, tenant reliability, backup, and cost controls. - **Cloud consolidation:** Bring independently created accounts and workloads under common identity, networking, policy, telemetry, and governance. - **Regulated workload migration:** Design data residency, access, encryption, logging, evidence, recovery, and supplier controls around assurance requirements. ### Architecture and integration - **Migration pattern per workload:** Select rehost, replatform, refactor, replace, retain, or retire from business value, risk, dependencies, and operating economics. - **Connectivity and coexistence:** Control routing, DNS, identity, data synchronisation, latency, security, and ownership while old and new environments coexist. - **Cutover evidence:** Define performance, functional, data, security, recovery, and operational checks that must pass before responsibility moves. ### Quality and control - **Secure by design:** Identity, permissions, secrets, data boundaries, dependencies, change controls, and recovery are addressed throughout delivery. - **Observable operation:** Metrics, logs, traces, quality, cost, failures, and service outcomes are made visible and actionable. - **Reproducible delivery:** Configuration, tests, infrastructure, pipelines, artefacts, changes, and recovery procedures are versioned and repeatable. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Cloud migration assessment and workload inventory - Target architecture, landing-zone, and security design - Migration patterns, waves, schedule, risk, and ownership plan - Infrastructure code, connectivity, deployment, and observability foundations - Data migration, rehearsal, cutover, rollback, and validation package - Runbooks, operating model, decommissioning, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Does every workload need to move to cloud?** No. We evaluate business value, technical fit, compliance, latency, dependencies, cost, lifecycle, and operational capability before recommending migration, retention, replacement, or retirement. - **Can Rokad migrate without a long outage?** Often yes. Approaches can include replication, staged data movement, parallel environments, traffic switching, read-only windows, blue-green cutover, and rollback, depending on the system. - **Can you migrate between cloud providers?** Yes. We assess service equivalence, data movement, provider dependencies, networking, identity, operations, contract, cost, and exit risk before designing the transition. - **What happens after migration?** We validate service objectives, close migration exceptions, optimise architecture and cost, transfer operating ownership, document runbooks, and decommission legacy resources safely. --- ## [Service specialisation] Platform engineering Canonical URL: https://rokad.co/en/services/cloud-devops/platform-engineering > Rokad builds internal developer platforms that standardise infrastructure, environments, delivery, observability, security, and service operations through self-service golden paths. Platform engineering treats shared engineering capabilities as a product for internal teams. Rokad designs platform interfaces, templates, service catalogues, environment workflows, deployment, observability, identity, policy, documentation, and support around real developer journeys. ### Designed for - **Engineering organisations slowed by operational tickets:** Replace repeated provisioning, access, environment, deployment, and diagnostics requests with governed self-service. - **Teams standardising several products or services:** Create consistent service patterns, environments, telemetry, security, and ownership without forcing identical architectures. - **Growing companies formalising developer experience:** Reduce cognitive load, onboarding time, fragmented tooling, and undocumented production practices. ### Challenges - **Developers must understand every infrastructure detail:** Teams repeatedly assemble networking, secrets, pipelines, telemetry, and deployment patterns instead of focusing on product work. - **Standards exist only as documents:** Security, reliability, naming, tagging, ownership, and observability are not encoded into the path teams actually use. - **A platform risks becoming another central bottleneck:** Without product management, feedback, service levels, and clear boundaries, internal tooling accumulates low-value complexity. ### Capabilities - Developer-journey research and platform product strategy - Service catalogue, golden paths, templates, scaffolding, and standards - Environment, infrastructure, database, secret, and access self-service - CI/CD, deployment, preview, promotion, rollback, and release interfaces - Observability, ownership, documentation, scorecards, and operational metadata - Policy, security, cost, reliability, and compliance guardrails - Platform telemetry, adoption, support, roadmap, and managed operation ### Solution components - **Platform interfaces:** Portal, API, CLI, repository templates, workflows, forms, documentation, and service catalogue used by engineering teams. - **Golden paths:** Supported patterns for creating, testing, deploying, observing, operating, and retiring common workload types. - **Control plane:** Identity, policy, infrastructure orchestration, secrets, environments, metadata, ownership, cost, and audit. - **Platform product operation:** Research, roadmap, telemetry, adoption, service levels, support, versioning, documentation, and deprecation. ### Use cases - **Application onboarding platform:** Create repositories, environments, pipelines, identity, telemetry, ownership, and production readiness from a governed template. - **Self-service environments:** Provision preview, development, test, and production resources with policy, budgets, expiry, and auditable ownership. - **Engineering service catalogue:** Make applications, APIs, dependencies, owners, runbooks, health, documentation, and operational standards discoverable. - **Multi-team delivery standardisation:** Encode common build, security, deployment, observability, and reliability requirements into reusable workflows. ### Architecture and integration - **Thin platform abstractions:** Hide repetitive complexity while preserving access to underlying capabilities when teams have justified specialised needs. - **API-first control plane:** Keep portal, CLI, automation, and integrations aligned through stable platform capabilities rather than interface-specific logic. - **Product metrics:** Measure adoption, lead time, failure, developer effort, support demand, reliability, cost, and satisfaction—not only platform uptime. ### Quality and control - **Secure by design:** Identity, permissions, secrets, data boundaries, dependencies, change controls, and recovery are addressed throughout delivery. - **Observable operation:** Metrics, logs, traces, quality, cost, failures, and service outcomes are made visible and actionable. - **Reproducible delivery:** Configuration, tests, infrastructure, pipelines, artefacts, changes, and recovery procedures are versioned and repeatable. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Developer-journey and platform capability assessment - Platform product strategy, target architecture, and roadmap - Service catalogue, templates, golden paths, and self-service workflows - Infrastructure, CI/CD, identity, policy, telemetry, and cost integrations - Platform metrics, support model, service levels, and operational controls - Developer, administrator, contribution, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Is platform engineering only for large companies?** No. Smaller teams benefit when repeated infrastructure and delivery work creates material delay or inconsistency, but the platform should remain proportionate to team size and complexity. - **Do we need a developer portal?** Not always. The right interface may be repository templates, APIs, workflows, CLI tools, documentation, or a portal. We begin with developer journeys and platform capabilities. - **How do you avoid over-abstracting the cloud?** We standardise common paths, expose underlying constraints, maintain escape routes for justified needs, and evaluate abstractions against user effort and operating cost. - **Can Rokad operate the platform after launch?** Yes. Managed platform services can cover roadmap, support, upgrades, reliability, security, cost, documentation, adoption, and new golden paths. --- ## [Service specialisation] CI/CD engineering Canonical URL: https://rokad.co/en/services/cloud-devops/ci-cd > Rokad designs and implements reliable CI/CD systems that move changes from source to production through automated quality, security, approval, deployment, and rollback controls. Continuous integration and delivery connect source control, dependencies, tests, artefacts, environments, infrastructure, security, approvals, deployments, telemetry, and recovery. Rokad builds pipelines that improve release speed while increasing evidence and control. ### Designed for - **Teams deploying through manual procedures:** Replace undocumented commands, individual access, and inconsistent environments with repeatable release workflows. - **Product organisations with slow or risky releases:** Improve feedback, test coverage, artefact integrity, promotion, deployment safety, and rollback readiness. - **Enterprises standardising delivery across teams:** Provide reusable pipeline patterns with controlled variation, policy, evidence, ownership, and platform support. ### Challenges - **A successful build does not prove production readiness:** Tests, security, configuration, migrations, dependencies, infrastructure, and operational checks are incomplete or disconnected. - **Each environment behaves differently:** Manual configuration, mutable servers, untracked secrets, and inconsistent dependencies make releases unpredictable. - **Rollback is theoretical:** Applications, databases, flags, jobs, queues, and integrations do not have tested recovery or compatibility plans. ### Capabilities - Source, branch, review, merge, version, and release workflow design - Build, dependency, cache, test, quality, security, and artefact pipelines - Infrastructure, configuration, secret, database, and environment delivery - Promotion, approval, policy, evidence, and segregation controls - Rolling, blue-green, canary, feature-flag, and progressive delivery - Rollback, compatibility, migration, recovery, and release validation - Pipeline observability, performance, reliability, cost, and reusable templates ### Solution components - **Integration pipeline:** Fast feedback for source, dependencies, types, tests, quality, security, artefact creation, and provenance. - **Delivery pipeline:** Environment configuration, infrastructure, deployment, migration, smoke tests, promotion, and approval. - **Release controls:** Policy, permissions, change records, evidence, separation, feature flags, traffic, and rollback decisions. - **Pipeline operation:** Queue time, duration, failure, flaky tests, runner capacity, cost, secrets, upgrades, support, and templates. ### Use cases - **Automate application delivery:** Move web, API, worker, mobile backend, or service changes through consistent test, artefact, deployment, and validation stages. - **Standardise multi-service pipelines:** Create reusable workflows, templates, policies, environments, and observability across repositories and teams. - **Add progressive delivery:** Reduce release risk with canaries, feature flags, automated analysis, traffic controls, and fast rollback. - **Modernise legacy release processes:** Introduce source control, build reproducibility, tests, artefacts, configuration, deployment automation, and change evidence incrementally. ### Architecture and integration - **Build once, promote:** Create an immutable verified artefact once and move it through environments rather than rebuilding differently at each stage. - **Environment parity with explicit differences:** Keep architecture and delivery consistent while versioning justified configuration, scale, data, and access differences. - **Database-safe delivery:** Use compatible schema changes, phased migrations, backfills, validation, and rollback or roll-forward strategies. ### Quality and control - **Secure by design:** Identity, permissions, secrets, data boundaries, dependencies, change controls, and recovery are addressed throughout delivery. - **Observable operation:** Metrics, logs, traces, quality, cost, failures, and service outcomes are made visible and actionable. - **Reproducible delivery:** Configuration, tests, infrastructure, pipelines, artefacts, changes, and recovery procedures are versioned and repeatable. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Delivery-process and pipeline assessment - Target CI/CD architecture, controls, and decision records - Reusable build, test, security, artefact, and deployment workflows - Environment, infrastructure, secret, migration, and promotion automation - Progressive delivery, validation, rollback, and release evidence - Pipeline runbooks, metrics, templates, and operating documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Can Rokad work with our existing CI platform?** Yes. We can improve GitHub Actions, GitLab CI, Azure DevOps, Jenkins, CircleCI, cloud-native systems, or other supported platforms before recommending replacement. - **Do automated pipelines remove approvals?** Not necessarily. Pipelines can automate evidence and routine checks while preserving risk-based human approval, segregation, change windows, or policy decisions. - **How do you handle secrets in CI/CD?** We minimise long-lived credentials, use scoped identities or workload federation where possible, central secret stores, protected environments, audit, rotation, and masked logs. - **Can databases be deployed safely through pipelines?** Yes. We use reviewed migrations, compatibility patterns, backups where relevant, rehearsal, validation, phased changes, observability, and roll-forward or rollback plans. --- ## [Platform service] GitHub Actions CI/CD services Canonical URL: https://rokad.co/en/services/cloud-devops/ci-cd/github-actions Platform: GitHub Actions > Rokad designs, secures, standardises, and operates GitHub Actions workflows for build, test, artefact, infrastructure, deployment, release, and supply-chain control. GitHub Actions can place delivery directly beside source and review, but production use requires reusable workflow architecture, protected environments, runner strategy, short-lived cloud identity, artefact integrity, concurrency, observability, cost controls, and accountable ownership. Rokad builds these capabilities as a supported delivery platform. ### Designed for - **Teams replacing manual or repository-specific delivery:** Create repeatable build, test, package, deploy, approve, validate, and rollback workflows across applications and environments. - **Organisations standardising GitHub delivery across repositories:** Introduce reusable workflows, organisation policy, runner boundaries, environments, permissions, attestations, and shared operational standards. - **Security-conscious teams removing long-lived deployment secrets:** Use OIDC, scoped permissions, protected environments, trusted reusable workflows, and auditable deployment identity. ### Implementation risks - **Every repository copies and modifies its own workflow:** Build, security, deployment, secrets, versions, and failure behaviour diverge without reusable platform ownership. - **Workflow permissions and third-party actions are overly broad:** Default tokens, unpinned dependencies, secrets, fork events, self-hosted runners, and cloud credentials expand the supply-chain risk. - **Production deployment is not a protected environment:** Approvals, concurrency, branch policy, change evidence, rollback, deployment history, and service validation are incomplete. ### Platform capabilities - Workflow and job architecture, matrices, dependencies, conditions, concurrency, caching, artefacts, and failure handling - Reusable workflows, composite actions, organisation templates, versioning, compatibility, ownership, and documentation - GitHub-hosted and self-hosted runner architecture, isolation, autoscaling, networks, images, patching, and capacity - Environments, approvals, branch and tag controls, secrets, variables, permissions, and deployment protection - OIDC federation to AWS, Azure, Google Cloud, registries, secret systems, and infrastructure platforms - Artefact attestations, provenance, dependency controls, action pinning, code scanning, and supply-chain evidence - Workflow observability, queue time, reliability, cost, incident response, migration, and managed CI/CD operation ### Implementation system - **Reusable workflow platform:** Versioned build, test, security, package, infrastructure, deployment, release, and notification contracts shared across repositories. - **Runner and trust model:** Hosted or self-hosted execution, network access, isolation, images, labels, autoscaling, permissions, secrets, and untrusted-code boundaries. - **Environment and release controls:** Approvals, OIDC, concurrency, policies, artefacts, attestations, deployment records, smoke tests, progressive delivery, and rollback. - **Actions operations:** Usage, queue time, failures, flaky tests, runner health, dependency updates, security alerts, support, and platform roadmap. ### Use cases - **Application CI/CD on GitHub:** Build, test, scan, package, deploy, validate, promote, and roll back web, API, worker, container, and infrastructure changes. - **Organisation-wide reusable workflows:** Provide governed delivery paths with controlled inputs, outputs, permissions, versions, policy, and contribution processes. - **Cloud deployment with OIDC:** Replace static cloud keys with federated workflow identity scoped by repository, environment, branch, and reusable workflow. - **GitHub Actions security and cost remediation:** Review permissions, dependencies, runners, caches, artefacts, secrets, usage, duplication, failures, and supply-chain exposure. ### Architecture - **Reusable workflows are treated as versioned APIs:** Define stable inputs, outputs, permissions, secrets, errors, compatibility, ownership, release, and deprecation expectations. - **Untrusted code never shares privileged runners:** Separate fork and pull-request workloads from deployment networks, credentials, persistent hosts, caches, and production access. - **OIDC claims are part of authorisation design:** Scope cloud trust to repositories, owners, environments, branches, tags, and trusted workflow paths rather than accepting any workflow token. ### Quality and governance - **Trusted build and artefact path:** Source, dependencies, runners, caches, builds, tests, attestations, artefacts, registries, and deployment identity remain traceable and controlled. - **Environment protection:** Approvals, policy, secrets, permissions, change evidence, concurrency, promotion, and rollback match production risk. - **Pipeline as an operated product:** Templates, runners, queue time, failures, flaky tests, cost, upgrades, documentation, and support are owned and continuously improved. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - GitHub Actions workflow, permission, runner, usage, security, and release assessment - Reusable-workflow, runner, environment, identity, artefact, and operating architecture - Production workflows, composite actions, templates, policies, and repository integrations - OIDC, environment, approval, artefact, attestation, security, and rollback controls - Runner automation, monitoring, queue, capacity, cost, incident, and maintenance workflows - Developer, platform, security, operator, contribution, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad replace cloud deployment secrets with GitHub OIDC?** Yes. We design the provider trust policy, workflow permissions, claims, environment controls, role scope, audit, testing, and migration from static credentials. - **Can Rokad build organisation-wide reusable workflows?** Yes. We define stable contracts, versions, permissions, runner requirements, documentation, tests, rollout, support, and controlled repository adoption. - **Can self-hosted GitHub runners be secured?** Yes. We assess isolation, ephemeral execution, networks, images, patching, autoscaling, credentials, untrusted events, cleanup, monitoring, and capacity. - **Can Rokad migrate pipelines from Jenkins or another system?** Yes. We map triggers, stages, agents, dependencies, artefacts, secrets, environments, approvals, integrations, deployment, and operational behaviour before migration. --- ## [Platform service] GitLab CI/CD engineering services Canonical URL: https://rokad.co/en/services/cloud-devops/ci-cd/gitlab-ci-cd Platform: GitLab CI/CD > Rokad designs, modernises, secures, and operates GitLab CI/CD pipelines, runners, components, environments, artefacts, and release workflows. GitLab CI/CD can connect source, review, build, test, security, artefacts, environments, deployment, and operations in one platform. Rokad structures pipeline architecture, components, includes, parent-child pipelines, runner fleets, protected resources, environments, credentials, observability, and lifecycle ownership. ### Designed for - **GitLab teams standardising delivery across projects:** Create reusable components, templates, policies, runner boundaries, environments, deployment controls, and shared platform ownership. - **Organisations operating complex monorepos or many services:** Use dynamic child pipelines, rules, needs, components, caching, artefacts, and selective execution without creating opaque YAML. - **Enterprises managing GitLab runners and protected delivery:** Design hosted or self-managed execution, isolation, scaling, networks, credentials, protected branches, and production environments. ### Implementation risks - **A single pipeline file contains every project concern:** Rules, stages, jobs, includes, variables, environments, and deployments become difficult to test, reuse, and change safely. - **Runner scope exposes privileged infrastructure:** Shared, group, project, protected, and untrusted workloads execute without clear isolation, network, credential, or cleanup boundaries. - **Pipeline complexity increases queue time and spend:** Duplicate jobs, poor rules, cache misses, large artefacts, serial stages, and oversized runners slow feedback and raise cost. ### Platform capabilities - GitLab pipeline stages, DAGs, rules, needs, matrices, caches, artefacts, reports, retries, and failure handling - CI/CD components, includes, templates, versioning, catalogues, ownership, compatibility, and documentation - Parent-child and multi-project pipelines, monorepo patterns, dynamic configuration, and cross-project orchestration - GitLab-hosted and self-managed runners, executors, autoscaling, isolation, networks, tags, capacity, and patching - Protected branches, tags, variables, environments, deployment approvals, freeze windows, credentials, and permissions - Container registry, package registry, security reports, dependencies, provenance, deployments, and release evidence - Pipeline analytics, queue time, cost, reliability, migrations, GitLab upgrades, support, and managed operation ### Implementation system - **Pipeline architecture:** Stages, DAGs, rules, components, child pipelines, artefacts, caches, reports, environments, and deployment contracts. - **Runner platform:** Hosted or self-managed runners, executors, images, networks, isolation, autoscaling, tags, credentials, patching, and capacity. - **Protected release path:** Branches, tags, variables, environments, approvals, deployments, evidence, policies, rollback, and production access. - **GitLab CI operations:** Usage, queue, duration, failures, caches, artefacts, runner health, versions, support, cost, and improvement backlog. ### Use cases - **GitLab CI/CD implementation:** Automate source validation, tests, security, build, artefacts, infrastructure, deployment, verification, promotion, and rollback. - **Monorepo and parent-child pipelines:** Generate and execute service-specific pipelines with explicit dependencies, ownership, components, environments, and reports. - **GitLab runner platform:** Build secure, autoscaled, observable runner pools for trusted, untrusted, privileged, networked, and specialised workloads. - **Pipeline and template modernisation:** Refactor duplicated YAML into governed components, reduce execution waste, improve security, and establish versioned adoption. ### Architecture - **Components expose narrow stable contracts:** Package common jobs with controlled inputs, outputs, dependencies, runner needs, permissions, versions, and documented behaviour. - **Runner scope matches workload trust:** Separate protected deployment, general build, untrusted contribution, privileged container, and private-network execution. - **Pipeline graph optimises for evidence and feedback:** Use DAG dependencies, selective rules, caching, parallelism, child pipelines, and artefact boundaries without removing required controls. ### Quality and governance - **Trusted build and artefact path:** Source, dependencies, runners, caches, builds, tests, attestations, artefacts, registries, and deployment identity remain traceable and controlled. - **Environment protection:** Approvals, policy, secrets, permissions, change evidence, concurrency, promotion, and rollback match production risk. - **Pipeline as an operated product:** Templates, runners, queue time, failures, flaky tests, cost, upgrades, documentation, and support are owned and continuously improved. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - GitLab pipeline, runner, component, permission, security, usage, and release assessment - Pipeline, component, runner, environment, artefact, identity, and operating architecture - Production pipelines, components, templates, child-pipeline patterns, and project integrations - Runner automation, protected resources, approvals, credentials, security, and rollback controls - Pipeline metrics, queue, capacity, cost, upgrade, incident, and support workflows - Developer, platform, security, operator, contribution, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad design reusable GitLab CI/CD components?** Yes. We define inputs, outputs, jobs, dependencies, runner requirements, versions, tests, documentation, ownership, rollout, and deprecation. - **Can Rokad improve large monorepo pipelines?** Yes. We analyse change detection, child pipelines, DAGs, rules, caching, artefacts, parallelism, runners, test selection, and deployment boundaries. - **Can Rokad operate self-managed GitLab runners?** Yes. Managed scope can include executors, images, networks, autoscaling, patching, secrets, isolation, monitoring, queue time, capacity, and incidents. - **Can pipelines be migrated into GitLab from Jenkins or GitHub Actions?** Yes. We map source events, jobs, agents, artefacts, secrets, environments, approvals, integrations, deployment, reports, and recovery before staged migration. --- ## [Platform service] Azure DevOps engineering services Canonical URL: https://rokad.co/en/services/cloud-devops/ci-cd/azure-devops Platform: Azure DevOps > Rokad designs, modernises, secures, and operates Azure DevOps pipelines, templates, agents, environments, approvals, artefacts, and enterprise release workflows. Azure DevOps supports source, work tracking, build, test, artefact, and deployment workflows across Microsoft and heterogeneous environments. Rokad structures YAML templates, stages, resources, agent pools, service connections, environments, checks, artefacts, deployment jobs, traceability, and long-term platform operations. ### Designed for - **Microsoft enterprises standardising application delivery:** Connect Azure Repos or external source, Azure Pipelines, Artifacts, Boards, environments, approvals, and cloud deployment under one operating model. - **Teams migrating classic release pipelines to YAML:** Create versioned multi-stage pipelines, templates, resources, environment checks, deployment jobs, and traceable promotion. - **Organisations operating private agents and hybrid targets:** Control agent pools, network access, service connections, machine targets, credentials, capacity, patching, and support. ### Implementation risks - **Classic and YAML delivery paths overlap:** Build definitions, release pipelines, variable groups, service connections, approvals, scripts, and environments duplicate behaviour. - **Service connections grant broad cloud access:** Persistent credentials, shared connections, project permissions, agent access, and environment rights exceed workload needs. - **Templates become a central bottleneck:** Required templates, parameters, versions, exceptions, contribution, testing, and support are not managed as a platform product. ### Platform capabilities - Azure Pipelines YAML, stages, jobs, deployment jobs, conditions, resources, matrices, dependencies, and failure handling - Templates, required-template controls, repositories, versioning, parameter contracts, compatibility, and contribution workflows - Microsoft-hosted and self-hosted agents, pools, capabilities, images, networks, scaling, maintenance, and capacity - Environments, approvals, checks, exclusive locks, business hours, branches, policies, variables, and production controls - Azure service connections, workload identity federation, Key Vault, secrets, permissions, audit, and cloud deployment - Azure Artifacts, test results, security, work-item traceability, release notes, deployments, and evidence - Pipeline analytics, migration, queue time, reliability, cost, Azure DevOps Server considerations, and managed operation ### Implementation system - **YAML delivery architecture:** Stages, jobs, templates, resources, artefacts, test and security results, environments, deployments, and promotion contracts. - **Agent and connection platform:** Hosted or private agents, pools, images, networks, service connections, workload identity, secrets, patching, and capacity. - **Environment governance:** Approvals, checks, locks, branch controls, required templates, permissions, change traceability, validation, and rollback. - **Azure DevOps operations:** Projects, agents, queues, failures, templates, service connections, licences, upgrades, support, cost, and roadmap. ### Use cases - **Azure Pipelines implementation:** Build, test, scan, package, provision, deploy, verify, promote, and recover applications and infrastructure across environments. - **Classic-to-YAML migration:** Move build and release definitions into reviewed pipelines with templates, environments, checks, deployment jobs, and version control. - **Enterprise pipeline template platform:** Create required and optional delivery templates with controlled inputs, versions, policies, documentation, and contribution. - **Hybrid and private deployment automation:** Operate private agents and environment resources for Azure, on-premises, Kubernetes, virtual machines, databases, and other clouds. ### Architecture - **Environment checks remain outside mutable pipeline code:** Use resource-owner approvals and checks where production controls must not be removed by a pipeline author. - **Workload identity narrows Azure access:** Use federated service connections and scoped roles instead of broad long-lived secrets where supported. - **Templates balance standards and controlled extension:** Define required security and release stages while exposing documented extension points for workload-specific needs. ### Quality and governance - **Trusted build and artefact path:** Source, dependencies, runners, caches, builds, tests, attestations, artefacts, registries, and deployment identity remain traceable and controlled. - **Environment protection:** Approvals, policy, secrets, permissions, change evidence, concurrency, promotion, and rollback match production risk. - **Pipeline as an operated product:** Templates, runners, queue time, failures, flaky tests, cost, upgrades, documentation, and support are owned and continuously improved. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Azure DevOps project, pipeline, agent, service-connection, permission, usage, and release assessment - YAML, template, agent, environment, identity, artefact, and operating architecture - Production pipelines, templates, environment resources, checks, and repository integrations - Workload identity, service connections, approvals, security, artefacts, and rollback controls - Agent automation, monitoring, queue, capacity, cost, upgrade, incident, and support workflows - Developer, platform, security, operator, contribution, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad migrate Azure DevOps classic pipelines to YAML?** Yes. We inventory stages, tasks, variables, agents, service connections, artefacts, approvals, environments, integrations, and release behaviour before staged migration. - **Can Azure Pipelines deploy outside Azure?** Yes. Pipelines and private agents can target suitable Kubernetes, virtual machine, data, on-premises, and other-cloud environments with appropriate identity and network design. - **Can Rokad set up workload identity federation?** Yes. We configure service connections, Entra applications or identities, role scope, claims, pipeline permissions, testing, audit, and migration from static secrets. - **Can Rokad operate self-hosted Azure DevOps agents?** Yes. Scope can include pools, images, patching, autoscaling, network access, tools, secrets, monitoring, queue time, capacity, incidents, and cost. --- ## [Platform service] Jenkins engineering and modernisation services Canonical URL: https://rokad.co/en/services/cloud-devops/ci-cd/jenkins Platform: Jenkins > Rokad stabilises, secures, modernises, migrates, and operates Jenkins controllers, agents, pipelines, shared libraries, plugins, credentials, and release workflows. Jenkins remains valuable where organisations need highly extensible self-managed delivery or must support specialised and legacy estates. Its flexibility also transfers responsibility for controllers, plugins, agents, credentials, backups, upgrades, pipeline standards, security, and availability. Rokad engineers and operates those responsibilities explicitly. ### Designed for - **Enterprises dependent on business-critical Jenkins delivery:** Stabilise controllers, agents, plugins, credentials, pipelines, backups, upgrades, monitoring, and support before failure or migration. - **Teams standardising many Jenkinsfiles:** Use shared libraries, declarative Pipeline, templates, folder controls, agents, artefacts, and documented delivery contracts. - **Organisations planning a CI platform migration:** Inventory jobs and dependencies, reduce technical debt, preserve release behaviour, and migrate in controlled waves. ### Implementation risks - **Controller availability is a hidden production dependency:** Backups, recovery, storage, configuration, plugin compatibility, upgrades, credentials, and capacity are not tested or owned. - **Plugin and shared-library changes affect every pipeline:** Versions, dependencies, sandbox permissions, compatibility, rollout, testing, and rollback lack lifecycle controls. - **Persistent agents accumulate privilege and state:** Workspaces, credentials, tools, Docker access, network access, caches, and untrusted jobs create cross-build and security risk. ### Platform capabilities - Jenkins controller, folder, job, Pipeline, plugin, credential, agent, storage, security, and reliability assessment - Declarative and scripted Pipeline, multibranch jobs, Jenkinsfiles, stages, post conditions, artefacts, and test reporting - Global and folder shared libraries, custom steps, versioning, testing, documentation, ownership, and rollout - Static, ephemeral, container, Kubernetes, cloud, Windows, Linux, and specialised agent architecture - Credentials, role-based access, folders, script approvals, secrets, network segmentation, audit, and hardening - Configuration as code, backups, recovery, high availability patterns, monitoring, logs, upgrades, and plugin governance - Migration to or from GitHub Actions, GitLab CI/CD, Azure DevOps, cloud-native systems, and managed Jenkins operation ### Implementation system - **Jenkins controller platform:** Configuration, storage, plugins, folders, credentials, security, backups, recovery, monitoring, upgrades, and administration. - **Pipeline and library system:** Jenkinsfiles, declarative contracts, shared libraries, custom steps, tests, artefacts, environments, deployment, and rollback. - **Agent estate:** Provisioning, images, labels, tools, networks, credentials, isolation, autoscaling, cleanup, capacity, patching, and telemetry. - **Jenkins operations:** Availability, queues, executors, failures, plugins, libraries, upgrades, incidents, support, cost, and migration roadmap. ### Use cases - **Jenkins stabilisation programme:** Recover ownership, inventory dependencies, secure access, test backups, improve agents, monitoring, upgrades, and operational runbooks. - **Shared Pipeline library platform:** Standardise build, test, security, artefact, infrastructure, deployment, evidence, and notifications across applications. - **Ephemeral Jenkins agents:** Replace persistent shared hosts with disposable container or cloud agents that isolate jobs and scale with demand. - **Jenkins migration:** Classify jobs, dependencies, agents, plugins, credentials, integrations, artefacts, environments, and business criticality before waves. ### Architecture - **Controller state is protected and recoverable:** Version configuration where possible, back up required state, secure secrets, test restoration, monitor capacity, and document recovery objectives. - **Shared libraries are versioned platform code:** Test changes, pin or control versions, define compatibility, review privileged steps, document contracts, and stage adoption. - **Agents are disposable trust zones:** Match agent pools to workload trust, privilege, tools, network, operating system, capacity, and cleanup requirements. ### Quality and governance - **Trusted build and artefact path:** Source, dependencies, runners, caches, builds, tests, attestations, artefacts, registries, and deployment identity remain traceable and controlled. - **Environment protection:** Approvals, policy, secrets, permissions, change evidence, concurrency, promotion, and rollback match production risk. - **Pipeline as an operated product:** Templates, runners, queue time, failures, flaky tests, cost, upgrades, documentation, and support are owned and continuously improved. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Jenkins controller, job, pipeline, plugin, library, agent, credential, security, and risk assessment - Controller, pipeline, library, agent, backup, recovery, migration, and operating architecture - Production Jenkinsfiles, shared libraries, configuration, folders, credentials, and integrations - Agent automation, isolation, images, scaling, monitoring, cleanup, and capacity controls - Backup, restoration, upgrade, plugin, security, incident, and support workflows - Developer, platform, administrator, security, migration, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad stabilise an old Jenkins installation before migration?** Yes. We first protect availability, credentials, backups, plugins, controllers, agents, pipelines, monitoring, and ownership so migration does not begin from an uncontrolled state. - **Can Rokad build Jenkins shared libraries?** Yes. We create reusable steps and pipeline patterns with contracts, versions, tests, documentation, permissions, rollout, support, and deprecation controls. - **Can Jenkins agents run on Kubernetes or cloud infrastructure?** Yes. We can design disposable agents with suitable images, tools, networks, credentials, resource controls, autoscaling, observability, and cleanup. - **Should Jenkins always be replaced?** No. The decision depends on specialised integrations, legacy environments, control requirements, current risk, migration value, team skills, operating cost, and available alternatives. --- ## [Service specialisation] Kubernetes services Canonical URL: https://rokad.co/en/services/cloud-devops/kubernetes > Rokad designs, implements, migrates, secures, and operates Kubernetes platforms for containerised workloads with explicit reliability, cost, and ownership controls. Kubernetes is valuable when workload scale, portability, delivery, isolation, platform standardisation, or operational requirements justify its complexity. Rokad assesses suitability, designs clusters and platform services, migrates workloads, and establishes secure long-term operation. ### Designed for - **Teams adopting containers across several services:** Create a consistent orchestration, deployment, networking, observability, policy, and operating foundation. - **Organisations stabilising an existing Kubernetes estate:** Improve upgrades, security, resource management, availability, cost, telemetry, and ownership. - **Platforms requiring controlled workload portability:** Standardise workload contracts across cloud, hybrid, edge, or dedicated environments where justified. ### Challenges - **Kubernetes was adopted before operating requirements were defined:** Clusters exist without clear tenancy, reliability, upgrade, cost, security, support, or developer-experience models. - **Workload configuration is inconsistent:** Resources, probes, disruption, autoscaling, secrets, policies, logging, and deployment practices vary by team. - **Cluster upgrades carry excessive risk:** Version dependencies, add-ons, APIs, workloads, nodes, and maintenance procedures lack evidence and rehearsal. ### Capabilities - Kubernetes suitability, workload, platform, and cost assessment - Managed, self-managed, cloud, hybrid, edge, and multi-cluster architecture - Cluster provisioning, networking, ingress, DNS, storage, identity, and secrets - Workload packaging, policies, resource controls, autoscaling, and disruption - GitOps, CI/CD, environments, progressive delivery, and developer workflows - Metrics, logs, traces, events, security, backup, recovery, and incident response - Version upgrades, capacity, reliability, cost, governance, and managed operation ### Solution components - **Cluster foundation:** Control plane, nodes, networks, storage, identity, DNS, ingress, secrets, add-ons, and lifecycle. - **Workload contract:** Images, configuration, resources, probes, policies, autoscaling, disruption, dependencies, and deployment behaviour. - **Platform services:** Delivery, observability, policy, certificates, registries, service networking, backup, developer access, and templates. - **Cluster operation:** Upgrades, capacity, incidents, security, cost, reliability, disaster recovery, support, and ownership. ### Use cases - **Container platform implementation:** Establish production and non-production clusters, shared services, delivery, telemetry, policy, and operating procedures. - **Workload migration to Kubernetes:** Adapt applications, configuration, storage, networking, health, deployment, and support for orchestrated operation. - **Kubernetes reliability programme:** Improve resource controls, availability, disruption, autoscaling, observability, upgrades, backup, and recovery. - **Multi-tenant internal platform:** Provide teams with governed namespaces, templates, quotas, access, delivery, telemetry, and support boundaries. ### Architecture and integration - **Cluster topology:** Choose account, region, environment, tenant, workload, and failure-domain boundaries based on isolation and operations. - **Stateful workload discipline:** Evaluate storage, backup, consistency, recovery, performance, placement, and managed-service alternatives before deployment. - **Upgrade as a continuous process:** Track versions and APIs, test add-ons and workloads, rehearse node and control-plane changes, and avoid unsupported drift. ### Quality and control - **Secure by design:** Identity, permissions, secrets, data boundaries, dependencies, change controls, and recovery are addressed throughout delivery. - **Observable operation:** Metrics, logs, traces, quality, cost, failures, and service outcomes are made visible and actionable. - **Reproducible delivery:** Configuration, tests, infrastructure, pipelines, artefacts, changes, and recovery procedures are versioned and repeatable. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Kubernetes suitability, workload, and current-state assessment - Cluster, tenancy, networking, storage, identity, and platform architecture - Infrastructure code, cluster configuration, policies, and shared services - Workload manifests, packaging, delivery, autoscaling, and reliability controls - Observability, security, backup, upgrade, and recovery implementation - Runbooks, service model, cost, governance, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Does our application need Kubernetes?** Not necessarily. We compare Kubernetes with simpler container, function, platform, and virtual-machine options based on workload count, team capability, scale, isolation, portability, and total operating cost. - **Can Rokad manage an existing Kubernetes cluster?** Yes. We assess architecture, versions, add-ons, workloads, access, security, resource use, reliability, backup, observability, cost, and operating ownership before handover. - **Can databases run on Kubernetes?** They can, but managed database services may provide a better risk and operating profile. We evaluate state, performance, recovery, skills, portability, and cost before recommending placement. - **How are Kubernetes upgrades handled?** We review compatibility, deprecated APIs, add-ons, node images, policies, workloads, capacity, backups, maintenance sequence, validation, and rollback or recovery before staged upgrades. --- ## [Platform service] Amazon EKS engineering services Canonical URL: https://rokad.co/en/services/cloud-devops/kubernetes/amazon-eks Platform: Amazon Elastic Kubernetes Service > Rokad designs, builds, migrates, secures, upgrades, and operates Amazon EKS platforms for production container workloads on AWS. Amazon EKS provides a managed Kubernetes control plane, while organisations remain responsible for cluster boundaries, VPC architecture, nodes, workload identity, add-ons, policies, storage, delivery, telemetry, upgrades, resilience, and cost. Rokad engineers these responsibilities as a supported platform rather than an isolated cluster. ### Designed for - **AWS teams standardising container workloads:** Create consistent EKS clusters, node platforms, networking, identity, add-ons, delivery, observability, and workload controls. - **Organisations migrating services into EKS:** Adapt applications, images, configuration, storage, networking, health, scaling, deployment, and support for Kubernetes operation. - **Companies stabilising an existing EKS estate:** Improve versions, node groups, add-ons, IAM, security, resource efficiency, telemetry, backup, reliability, and ownership. ### Implementation risks - **EKS was created without a platform boundary:** Clusters, accounts, regions, environments, tenants, node groups, add-ons, networks, and support responsibilities do not align. - **AWS and Kubernetes identity are loosely connected:** Human access, roles, service accounts, pod permissions, secrets, cluster administration, and audit create excessive privilege. - **Cluster upgrades are delayed until support pressure:** Kubernetes versions, AMIs, add-ons, APIs, controllers, workloads, and disruption are not continuously tested. ### Platform capabilities - EKS suitability, account, region, cluster, tenancy, workload, cost, and operating assessment - VPC, subnet, endpoint, load balancer, ingress, DNS, service, egress, private-cluster, and hybrid connectivity architecture - Managed node groups, Fargate, autoscaling, node images, architectures, capacity, spot, scheduling, and workload placement - IAM, access entries, workload identity, service accounts, secrets, KMS, policies, admission, image, and runtime security - EBS, EFS, S3 integration, stateful workloads, backup, restore, disaster recovery, and data-service decisions - Helm, GitOps, CI/CD, registries, add-ons, observability, logging, tracing, policy, and developer golden paths - Version and add-on upgrades, reliability, performance, cost, incidents, runbooks, and managed EKS operation ### Implementation system - **EKS cluster foundation:** AWS accounts, regions, VPCs, subnets, endpoints, control plane, node platforms, DNS, storage, and shared add-ons. - **Identity and workload controls:** Human access, IAM, workload identity, RBAC, namespaces, policies, secrets, images, resources, quotas, and isolation. - **Delivery and observability:** Registries, Helm, GitOps, pipelines, progressive delivery, metrics, logs, traces, alerts, service objectives, and runbooks. - **EKS operations:** Versions, add-ons, node images, capacity, incidents, backup, recovery, security, cost, support, and lifecycle ownership. ### Use cases - **Production EKS platform:** Establish cluster, network, node, identity, add-on, storage, delivery, observability, security, and operating foundations. - **Application migration to EKS:** Containerise and adapt services through workload assessment, deployment contracts, data decisions, testing, cutover, and support transition. - **Multi-team EKS platform:** Provide governed namespaces, accounts, templates, policies, quotas, access, telemetry, delivery, and service boundaries. - **EKS upgrade and reliability programme:** Modernise versions, nodes, add-ons, policies, autoscaling, disruption, telemetry, backup, recovery, and operational readiness. ### Architecture - **Cluster boundaries follow blast radius and ownership:** Separate accounts, regions, environments, teams, regulated workloads, and critical services when isolation or lifecycle requires it. - **Pod access uses workload identity:** Give service accounts scoped AWS permissions without distributing node credentials or long-lived application keys. - **Managed AWS services remain valid workload dependencies:** Use RDS, DynamoDB, S3, queues, caches, and other services when they provide a better reliability and ownership model than running state in-cluster. ### Quality and governance - **Supported lifecycle:** Cluster versions, node images, APIs, add-ons, operators, workloads, backups, and upgrade paths remain tested and supportable. - **Workload and tenancy controls:** Identity, namespaces, policies, secrets, resources, disruption, autoscaling, networking, storage, and isolation are explicit. - **Observable platform operation:** Control plane, nodes, workloads, networking, storage, delivery, security, capacity, cost, and incidents are visible to accountable operators. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - EKS cluster, workload, VPC, identity, add-on, security, cost, and risk assessment - Cluster, tenancy, network, node, storage, identity, delivery, and operating architecture - Infrastructure code, EKS clusters, node groups, add-ons, policies, and shared services - Workload packaging, GitOps, CI/CD, autoscaling, resource, and reliability controls - Observability, backup, recovery, upgrade, security, cost, and incident workflows - Developer, platform, security, operator, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad build private Amazon EKS clusters?** Yes. We design endpoint access, VPC routing, DNS, egress, bastion or controlled administration, private registries, AWS service access, and operational connectivity. - **Should EKS use managed node groups or Fargate?** The decision depends on workload control, daemon requirements, networking, storage, architecture, scaling, cost, isolation, and operational preferences. Mixed designs are possible. - **Can Rokad migrate an existing Kubernetes cluster to EKS?** Yes. We assess APIs, workloads, storage, ingress, identity, policies, add-ons, images, observability, backups, data, and cutover requirements. - **Can Rokad manage EKS after launch?** Yes. Managed services can cover upgrades, nodes, add-ons, delivery, observability, incidents, security, backup, recovery, capacity, cost, and platform roadmap. --- ## [Platform service] Azure Kubernetes Service engineering Canonical URL: https://rokad.co/en/services/cloud-devops/kubernetes/azure-aks Platform: Azure Kubernetes Service > Rokad designs, builds, migrates, secures, upgrades, and operates Azure Kubernetes Service platforms for production container workloads. AKS integrates Kubernetes with Microsoft Entra, Azure networking, registries, policy, monitoring, security, storage, and wider platform services. Rokad designs cluster boundaries, node pools, workload identity, network and ingress, add-ons, delivery, telemetry, upgrades, resilience, cost, and support as one operating platform. ### Designed for - **Azure teams adopting Kubernetes for production services:** Create controlled AKS foundations with Entra, networking, registries, nodes, policy, delivery, observability, security, and support. - **Organisations migrating containers or legacy applications:** Adapt workloads, configuration, storage, networking, identity, scaling, deployment, and operational ownership for AKS. - **Enterprises standardising multiple AKS clusters:** Align subscriptions, regions, environments, node pools, policies, add-ons, monitoring, upgrades, cost, and governance. ### Implementation risks - **AKS clusters bypass the Azure landing-zone model:** Subscriptions, virtual networks, private endpoints, DNS, identities, policies, logs, budgets, and ownership are inconsistent. - **Entra, Azure RBAC, and Kubernetes RBAC overlap:** Cluster administrators, groups, managed identities, service accounts, roles, secrets, and application access become difficult to reason about. - **Node and Kubernetes lifecycle are reactive:** Versions, node images, operating systems, add-ons, APIs, maintenance windows, workloads, and disruption are not rehearsed continuously. ### Platform capabilities - AKS suitability, subscription, region, cluster, tenancy, workload, cost, and support assessment - Virtual networks, private clusters, private DNS, ingress, load balancing, egress, firewall, service mesh, and hybrid connectivity - System and user node pools, autoscaling, spot, Windows and Linux nodes, images, scheduling, capacity, and maintenance - Microsoft Entra, Azure RBAC, Kubernetes RBAC, workload identity, managed identities, Key Vault, policy, and secrets - Azure Container Registry, disks, files, managed databases, stateful workload decisions, backup, restore, and recovery - Helm, GitOps, Azure DevOps, GitHub Actions, progressive delivery, Azure Monitor, logs, traces, policy, and golden paths - Kubernetes and node upgrades, Defender, reliability, performance, cost, incidents, runbooks, and managed AKS operation ### Implementation system - **AKS cluster foundation:** Subscriptions, networks, private connectivity, control plane, node pools, registries, DNS, storage, and shared add-ons. - **Identity and policy:** Entra groups, Azure and Kubernetes RBAC, managed identities, workload identity, namespaces, policy, secrets, and audit. - **Delivery and telemetry:** Helm, GitOps, pipelines, registries, progressive release, Monitor, logs, traces, alerts, objectives, and runbooks. - **AKS operations:** Versions, node images, add-ons, maintenance, capacity, incidents, backup, recovery, security, cost, and support. ### Use cases - **Production private AKS platform:** Establish subscriptions, networking, private access, identity, nodes, add-ons, delivery, telemetry, security, and operating procedures. - **Application modernisation on AKS:** Containerise services and connect Azure data, messaging, identity, secrets, monitoring, deployment, and recovery capabilities. - **Enterprise multi-cluster AKS governance:** Standardise clusters, policies, identities, networks, add-ons, templates, observability, upgrades, budgets, and ownership. - **AKS version and node migration:** Assess deprecated versions and images, test compatibility, build replacement pools, move workloads, validate, and retire old capacity. ### Architecture - **Cluster and subscription boundaries align:** Separate environments and critical domains according to policy, network, billing, identity, blast radius, and lifecycle ownership. - **Workload identity is preferred over embedded secrets:** Use Entra-backed pod identity and scoped Azure roles for Key Vault, registries, storage, databases, and other services. - **Node lifecycle is independent from application release:** Use pools, surge capacity, disruption controls, maintenance windows, image tracking, and workload validation to update safely. ### Quality and governance - **Supported lifecycle:** Cluster versions, node images, APIs, add-ons, operators, workloads, backups, and upgrade paths remain tested and supportable. - **Workload and tenancy controls:** Identity, namespaces, policies, secrets, resources, disruption, autoscaling, networking, storage, and isolation are explicit. - **Observable platform operation:** Control plane, nodes, workloads, networking, storage, delivery, security, capacity, cost, and incidents are visible to accountable operators. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - AKS cluster, workload, subscription, network, identity, add-on, security, cost, and risk assessment - Cluster, tenancy, network, node-pool, storage, identity, delivery, and operating architecture - Infrastructure code, AKS clusters, node pools, registries, policies, and shared services - Workload packaging, GitOps, CI/CD, autoscaling, resource, and reliability controls - Azure Monitor, Defender, backup, recovery, upgrade, cost, and incident workflows - Developer, platform, security, operator, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad build private AKS clusters?** Yes. We design private API access, DNS, virtual networks, firewall and egress, registries, private endpoints, administration, and operational connectivity. - **Can AKS use Microsoft Entra workload identity?** Yes. We configure service accounts, federated identity, managed identities, Azure roles, Key Vault or service access, audit, and migration from static credentials. - **Can Rokad migrate Windows containers to AKS?** Where workload and platform support align, we assess application dependencies, images, node pools, networking, storage, identity, licensing, observability, and support requirements. - **Can Rokad manage AKS upgrades?** Yes. We review Kubernetes versions, node images, APIs, add-ons, policies, workloads, capacity, disruption, backup, maintenance, validation, and recovery. --- ## [Platform service] Google Kubernetes Engine services Canonical URL: https://rokad.co/en/services/cloud-devops/kubernetes/google-gke Platform: Google Kubernetes Engine > Rokad designs, builds, migrates, secures, upgrades, and operates Google Kubernetes Engine platforms for production container workloads. GKE provides managed Kubernetes through Standard and Autopilot operating models, integrated with Google Cloud identity, networking, registries, policy, monitoring, security, data, and fleet capabilities. Rokad selects and engineers the cluster model, workload contracts, delivery, telemetry, upgrades, resilience, cost, and ownership. ### Designed for - **Google Cloud teams building container platforms:** Establish GKE clusters or fleets with projects, networks, identity, security, delivery, observability, data, and support foundations. - **Teams evaluating Autopilot and Standard modes:** Select the operating model by workload privileges, node control, networking, performance, compliance, cost, and team capability. - **Organisations modernising existing GKE estates:** Improve versions, fleets, networking, identity, policies, resource efficiency, telemetry, backup, reliability, and ownership. ### Implementation risks - **Cluster and Google Cloud project boundaries conflict:** Environments, fleets, networks, service accounts, data, logging, billing, policy, and support are partitioned inconsistently. - **Autopilot or Standard was selected without workload evidence:** Privilege, daemon, node, hardware, network, scheduling, cost, and operational requirements emerge after adoption. - **Rapid GKE lifecycle creates upgrade drift:** Release channels, versions, nodes, APIs, add-ons, policies, workloads, maintenance, and compatibility lack continuous review. ### Platform capabilities - GKE suitability, Standard or Autopilot selection, project, region, fleet, cluster, workload, cost, and support assessment - VPC-native clusters, Shared VPC, private clusters, DNS, ingress, Gateway API, load balancing, egress, and service networking - Node pools, Autopilot, autoscaling, spot, accelerators, architectures, scheduling, capacity, release channels, and maintenance - Cloud IAM, GKE RBAC, Workload Identity Federation for GKE, Secret Manager, policy, admission, image, and runtime security - Persistent disks, file and object integration, managed databases, stateful decisions, backup, restore, and recovery - Artifact Registry, Helm, GitOps, Cloud Build, GitHub Actions, progressive delivery, Cloud Operations, logging, traces, and golden paths - Fleet governance, version upgrades, Security Command Center integration, reliability, cost, incidents, and managed GKE operation ### Implementation system - **GKE cluster and fleet foundation:** Projects, regions, VPCs, private access, Standard or Autopilot clusters, nodes, fleets, DNS, storage, and add-ons. - **Identity and workload policy:** Cloud IAM, Kubernetes RBAC, workload identity, namespaces, policies, secrets, images, resources, quotas, and isolation. - **Delivery and observability:** Artifact Registry, Helm, GitOps, pipelines, progressive release, metrics, logs, traces, alerts, objectives, and runbooks. - **GKE operations:** Release channels, versions, nodes, fleets, capacity, incidents, backup, recovery, security, cost, and support. ### Use cases - **GKE Autopilot application platform:** Run compatible services with reduced node administration while preserving identity, delivery, policy, observability, data, and reliability controls. - **GKE Standard specialised platform:** Support workloads requiring node control, accelerators, specialised networking, system components, scheduling, or operating customisation. - **Multi-project GKE fleet:** Standardise membership, configuration, policy, identity, networking, telemetry, delivery, upgrades, and ownership across clusters. - **Kubernetes migration to GKE:** Map workloads, storage, ingress, identity, add-ons, policies, APIs, telemetry, backup, cutover, validation, and support transition. ### Architecture - **Autopilot is chosen from workload constraints:** Validate privilege, daemon, node, network, storage, hardware, security, performance, and cost requirements before selecting it. - **Project, fleet, and cluster boundaries serve different purposes:** Design billing and policy, multi-cluster governance, and workload isolation separately instead of forcing one hierarchy to carry every concern. - **Release channels become an operating commitment:** Select lifecycle pace, maintenance windows, compatibility testing, disruption controls, and exception procedures deliberately. ### Quality and governance - **Supported lifecycle:** Cluster versions, node images, APIs, add-ons, operators, workloads, backups, and upgrade paths remain tested and supportable. - **Workload and tenancy controls:** Identity, namespaces, policies, secrets, resources, disruption, autoscaling, networking, storage, and isolation are explicit. - **Observable platform operation:** Control plane, nodes, workloads, networking, storage, delivery, security, capacity, cost, and incidents are visible to accountable operators. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - GKE cluster, fleet, workload, project, network, identity, security, cost, and risk assessment - Cluster, fleet, tenancy, network, node, storage, identity, delivery, and operating architecture - Terraform, GKE clusters, fleets, node pools, policies, registries, and shared services - Workload packaging, GitOps, CI/CD, autoscaling, resource, and reliability controls - Cloud Operations, backup, recovery, upgrade, security, cost, and incident workflows - Developer, platform, security, operator, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Should we choose GKE Autopilot or Standard?** We compare workload privileges, node control, daemon needs, hardware, networking, storage, compliance, scaling, cost, and operational capability before recommending a mode. - **Can Rokad build private GKE clusters?** Yes. We design private control-plane and node access, Shared VPC, DNS, egress, service access, administration, registries, and operational connectivity. - **Can GKE workloads use Google Cloud services without keys?** Yes. We configure Workload Identity Federation for GKE and scoped IAM access to storage, databases, messaging, secrets, data, and other services. - **Can Rokad manage GKE upgrades and fleets?** Yes. Scope can include release channels, versions, nodes, APIs, add-ons, fleets, policies, workload compatibility, maintenance, validation, and recovery. --- ## [Platform service] Red Hat OpenShift engineering services Canonical URL: https://rokad.co/en/services/cloud-devops/kubernetes/red-hat-openshift Platform: Red Hat OpenShift > Rokad designs, builds, migrates, extends, secures, upgrades, and operates Red Hat OpenShift platforms across cloud, hybrid, and dedicated environments. OpenShift adds an opinionated enterprise application platform, Operators, integrated lifecycle, security controls, developer workflows, and hybrid deployment options around Kubernetes. Rokad designs cluster topology, infrastructure, identity, Operators, networking, storage, GitOps, developer experience, observability, upgrades, support, and governance as a coherent platform product. ### Designed for - **Enterprises standardising Kubernetes with vendor support:** Create governed container and application platforms with Operators, security, lifecycle, developer tooling, observability, and support. - **Organisations operating hybrid or regulated environments:** Deploy consistent platform capabilities across datacentre, cloud, edge, or managed OpenShift while respecting local boundaries. - **Teams modernising applications onto OpenShift:** Adapt workloads, build processes, images, storage, networking, identity, policy, delivery, and support to platform standards. ### Implementation risks - **OpenShift is deployed as infrastructure rather than a platform product:** Operators, templates, GitOps, developer access, security, service levels, support, adoption, and roadmap lack ownership. - **Operator lifecycle and cluster lifecycle are not coordinated:** Channel, version, dependencies, custom resources, workloads, storage, networking, and upgrade paths create hidden coupling. - **Legacy workloads conflict with restricted security defaults:** Images, users, filesystem, privileges, ports, volumes, network, and runtime expectations require controlled remediation. ### Platform capabilities - OpenShift suitability, edition, managed or self-managed model, infrastructure, subscription, cluster, workload, and cost assessment - OpenShift Container Platform, managed OpenShift, cloud, datacentre, hybrid, edge, disconnected, and multi-cluster architecture - Cluster installation, machine pools, networking, ingress, DNS, storage, identity, certificates, registries, and platform services - Operators, Operator Lifecycle Manager, custom resources, service mesh, serverless, pipelines, GitOps, and developer workflows - Projects, RBAC, security context constraints, policies, secrets, images, supply chain, network policy, and compliance controls - Application migration, build and image strategy, templates, Helm, GitOps, CI/CD, observability, logging, tracing, and backup - Cluster and Operator upgrades, capacity, reliability, recovery, support, incident, subscription, cost, and managed operation ### Implementation system - **OpenShift infrastructure:** Clusters, machines, cloud or datacentre integration, networking, ingress, DNS, storage, identity, certificates, and registries. - **Application platform services:** Operators, GitOps, pipelines, templates, service mesh, serverless, builds, registries, developer interfaces, and golden paths. - **Security and governance:** Projects, RBAC, security contexts, policy, secrets, images, network isolation, audit, compliance, and delegated ownership. - **OpenShift operations:** Versions, channels, Operators, machines, capacity, incidents, backup, recovery, subscriptions, cost, support, and roadmap. ### Use cases - **Enterprise OpenShift platform:** Build supported cluster, identity, network, storage, Operator, GitOps, observability, security, and service-management foundations. - **Application migration to OpenShift:** Remediate images and runtime expectations, package workloads, connect data and services, test, cut over, and transfer ownership. - **Hybrid OpenShift operating model:** Standardise platform and workload controls across managed cloud, self-managed cloud, datacentre, and edge clusters. - **OpenShift lifecycle recovery:** Address unsupported versions, Operator drift, security findings, capacity, storage, backup, telemetry, and upgrade blockers. ### Architecture - **Operators are production software dependencies:** Track ownership, channels, versions, permissions, custom resources, compatibility, support, backup, and upgrade impact. - **Security defaults shape application migration:** Remediate privileges, users, filesystems, capabilities, secrets, images, ports, and network access rather than weakening the whole platform. - **Hybrid consistency does not require identical infrastructure:** Standardise workload, policy, GitOps, identity, telemetry, and support contracts while allowing environment-specific infrastructure. ### Quality and governance - **Supported lifecycle:** Cluster versions, node images, APIs, add-ons, operators, workloads, backups, and upgrade paths remain tested and supportable. - **Workload and tenancy controls:** Identity, namespaces, policies, secrets, resources, disruption, autoscaling, networking, storage, and isolation are explicit. - **Observable platform operation:** Control plane, nodes, workloads, networking, storage, delivery, security, capacity, cost, and incidents are visible to accountable operators. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - OpenShift edition, infrastructure, cluster, Operator, workload, security, subscription, cost, and risk assessment - Cluster, hybrid, tenancy, network, storage, identity, Operator, delivery, and operating architecture - Infrastructure, OpenShift clusters, machine pools, Operators, policies, registries, and shared services - Application packaging, migration, GitOps, pipelines, templates, resource, and reliability controls - Observability, backup, recovery, upgrade, security, subscription, cost, and incident workflows - Developer, platform, security, operator, support, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad work with managed and self-managed OpenShift?** Yes. We evaluate provider responsibility, infrastructure, network, identity, Operators, subscriptions, security, lifecycle, support, and workload needs for the selected model. - **Can Rokad migrate standard Kubernetes workloads to OpenShift?** Yes. We assess APIs, images, security contexts, storage, ingress, identity, policies, Operators, delivery, telemetry, data, and cutover requirements. - **Can Rokad help with OpenShift Operators and GitOps?** Yes. We design Operator selection and lifecycle, GitOps repositories, promotion, secrets, policies, applications, drift, observability, rollback, and ownership. - **Can Rokad manage OpenShift upgrades?** Yes. We review channels, supported paths, Operators, APIs, machines, storage, networking, workloads, capacity, backups, maintenance, validation, and recovery. --- ## [Service specialisation] DevSecOps services Canonical URL: https://rokad.co/en/services/cloud-devops/devsecops > Rokad integrates security into engineering and delivery workflows through automated checks, policy, secure defaults, evidence, remediation, and operational feedback. DevSecOps makes security part of the system teams use to build and operate software. Rokad connects threat modelling, source control, dependencies, artefacts, infrastructure, secrets, identity, deployment, runtime telemetry, vulnerability management, and remediation to delivery workflows. ### Designed for - **Product teams formalising secure delivery:** Introduce practical security controls without creating a separate manual process for every release. - **Organisations preparing for enterprise assurance:** Create repeatable evidence for access, change, dependency, vulnerability, environment, and operational controls. - **Teams reducing security backlog and exposure:** Prioritise findings by reachability, exploitability, asset criticality, and remediation path rather than scanner volume alone. ### Challenges - **Security checks occur too late:** Critical architecture, dependency, identity, secret, and infrastructure decisions are discovered during audit or after release. - **Tools generate findings without ownership:** Alerts lack context, prioritisation, service mapping, remediation expectations, exceptions, and closure evidence. - **Developers bypass controls that slow delivery:** Security is not encoded into templates, environments, workflows, documentation, or supported engineering paths. ### Capabilities - Secure development lifecycle, threat modelling, ownership, and policy design - Source, secret, dependency, licence, static, dynamic, and API security checks - Software bill of materials, artefact signing, provenance, registries, and supply chain - Infrastructure, container, Kubernetes, cloud, network, and configuration policy - Identity, privilege, credentials, environments, approvals, and segregation - Vulnerability intake, prioritisation, remediation, exceptions, and evidence - Runtime telemetry, detection, incident feedback, metrics, training, and continuous improvement ### Solution components - **Secure engineering path:** Threat prompts, templates, dependencies, secrets, tests, reviews, documentation, and secure defaults in daily work. - **Supply-chain controls:** Source protection, dependency policy, builds, artefacts, provenance, signatures, registries, and deployment verification. - **Policy and evidence:** Machine-checkable rules, approvals, exceptions, ownership, findings, remediation, and assurance records. - **Operational feedback:** Runtime vulnerabilities, incidents, detections, attack paths, service telemetry, lessons, and control improvement. ### Use cases - **Secure CI/CD implementation:** Add risk-based checks, artefact controls, policy, approvals, provenance, and deployment verification to delivery pipelines. - **Cloud and infrastructure policy:** Enforce identity, network, encryption, logging, secret, backup, tagging, and configuration requirements through code. - **Software supply-chain security:** Control source, dependencies, builds, runners, artefacts, registries, signatures, deployment identity, and provenance. - **Vulnerability-management integration:** Connect findings to assets, owners, exploitability, service risk, remediation workflow, exceptions, and closure evidence. ### Architecture and integration - **Risk-based gates:** Block releases only where risk and confidence justify it; route lower-risk findings into owned remediation workflows. - **Short-lived identity:** Prefer workload and federated identity over static credentials and scope every source, runner, environment, and deployment action. - **Evidence as pipeline output:** Produce test, scan, approval, artefact, provenance, deployment, and configuration records automatically for each release. ### Quality and control - **Secure by design:** Identity, permissions, secrets, data boundaries, dependencies, change controls, and recovery are addressed throughout delivery. - **Observable operation:** Metrics, logs, traces, quality, cost, failures, and service outcomes are made visible and actionable. - **Reproducible delivery:** Configuration, tests, infrastructure, pipelines, artefacts, changes, and recovery procedures are versioned and repeatable. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - DevSecOps maturity, workflow, tooling, and risk assessment - Secure delivery architecture, policy, ownership, and roadmap - Integrated source, dependency, secret, artefact, infrastructure, and application checks - Identity, approval, exception, remediation, and evidence workflows - Security dashboards, service mapping, metrics, and operational feedback - Developer guidance, runbooks, governance, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Will security checks slow every release?** They should not. We optimise feedback speed, run checks at the appropriate stage, cache or parallelise work, use risk-based gates, and keep lower-risk findings in managed remediation workflows. - **Can Rokad work with our existing security tools?** Yes. We assess coverage, signal quality, integration, ownership, workflow, cost, and duplication before adding or replacing tools. - **How are false positives handled?** Findings are enriched with asset, path, reachability, context, severity, and ownership. Exceptions require reason, scope, expiry, approval, and review rather than permanent suppression. - **Does DevSecOps replace penetration testing?** No. Continuous engineering controls reduce recurring risk, while independent penetration testing and specialised reviews remain valuable for defined scopes and threat scenarios. --- ## [Service specialisation] Site reliability engineering Canonical URL: https://rokad.co/en/services/cloud-devops/site-reliability-engineering > Rokad applies SRE practices to define reliability targets, improve observability, reduce operational toil, strengthen incident response, and engineer resilient production services. Reliability is a product and engineering decision, not only an operations task. Rokad helps teams define service objectives, measure user-impacting behaviour, manage error budgets, improve incident response, automate toil, plan capacity, test recovery, and prioritise reliability work. ### Designed for - **Product teams experiencing recurring incidents:** Move from reactive firefighting to measurable service objectives, owned failure modes, and systematic improvement. - **Organisations scaling critical digital services:** Prepare architecture, capacity, observability, on-call, recovery, and operational ownership for higher demand and impact. - **Teams balancing feature speed and stability:** Use error budgets and production evidence to make explicit release and reliability trade-offs. ### Challenges - **Uptime metrics do not reflect user experience:** The organisation cannot connect availability, latency, correctness, freshness, and dependency behaviour to real journeys. - **Incidents repeat without structural learning:** Response focuses on restoration but not failure analysis, contributing conditions, follow-through, ownership, or prevention. - **Operational toil consumes engineering capacity:** Manual checks, releases, access, scaling, remediation, and support interrupt product work and create human dependency. ### Capabilities - Critical-user-journey, service-level indicator, objective, and error-budget design - Metrics, logs, traces, events, synthetics, real-user, and dependency observability - Alert quality, on-call, escalation, incident command, communication, and review - Capacity, load, performance, saturation, queue, and dependency analysis - Resilience, redundancy, graceful degradation, fault isolation, and chaos exercises - Backup, recovery, disaster scenarios, continuity, and recovery testing - Toil measurement, automation, reliability backlog, reporting, and embedded SRE support ### Solution components - **Reliability model:** User journeys, service boundaries, indicators, objectives, dependencies, error budgets, and ownership. - **Production intelligence:** Telemetry, dashboards, alerts, traces, logs, events, synthetics, service maps, and diagnostic context. - **Incident system:** On-call, severity, command, escalation, communication, restoration, review, actions, and learning. - **Reliability engineering:** Capacity, resilience, automation, recovery, dependency controls, release safety, and prioritised risk reduction. ### Use cases - **SLO implementation:** Define measurable reliability targets for critical journeys and connect error budgets to release and improvement decisions. - **Incident-response transformation:** Establish on-call, severity, communication, runbooks, command, post-incident review, and action tracking. - **Observability redesign:** Replace disconnected dashboards and noisy alerts with service-oriented telemetry and diagnostic workflows. - **Resilience and recovery programme:** Test capacity, dependency failure, backup, restore, regional loss, degraded modes, and disaster procedures. ### Architecture and integration - **User-centred indicators:** Measure availability, latency, correctness, freshness, and durability at the point users depend on the service. - **Failure-domain isolation:** Limit propagation across tenants, regions, dependencies, queues, workloads, data, and operational changes. - **Recovery as a tested capability:** Define recovery objectives, automate where practical, rehearse regularly, measure outcomes, and close evidence gaps. ### Quality and control - **Secure by design:** Identity, permissions, secrets, data boundaries, dependencies, change controls, and recovery are addressed throughout delivery. - **Observable operation:** Metrics, logs, traces, quality, cost, failures, and service outcomes are made visible and actionable. - **Reproducible delivery:** Configuration, tests, infrastructure, pipelines, artefacts, changes, and recovery procedures are versioned and repeatable. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Reliability, incident, observability, capacity, and recovery assessment - Critical journeys, service map, SLIs, SLOs, and error-budget policy - Telemetry, dashboards, alerts, synthetics, traces, and diagnostic improvements - On-call, incident command, communication, review, and action workflows - Capacity, resilience, backup, recovery, and failure-exercise programme - Reliability backlog, runbooks, reporting, ownership, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **What is an SLO?** A service-level objective is a target for a measured aspect of user-relevant service behaviour, such as successful requests, latency, correctness, freshness, or durability over a defined period. - **Does SRE require a separate team?** No. Practices can be embedded within product and platform teams, supported by a central group, or delivered through a dedicated team depending on scale and service criticality. - **Can Rokad provide on-call support?** Managed coverage can be defined by service criticality, hours, response targets, escalation, access, runbooks, dependencies, and commercial structure. - **How do you reduce alert fatigue?** We connect alerts to user impact and required action, remove duplicate or unactionable signals, improve grouping and context, tune thresholds, and review alert outcomes. --- ## [Platform service] Datadog observability services Canonical URL: https://rokad.co/en/services/cloud-devops/site-reliability-engineering/datadog Platform: Datadog > Rokad implements, rationalises, governs, and operates Datadog observability across infrastructure, applications, logs, user experience, service objectives, and incidents. Datadog can correlate infrastructure, APM, logs, user experience, synthetic tests, security signals, objectives, and incidents. Rokad designs service and ownership models, instrumentation, tags, monitors, dashboards, SLOs, retention, sampling, access, incident workflows, and telemetry economics so the platform supports decisions rather than alert volume. ### Designed for - **Teams consolidating fragmented monitoring tools:** Bring infrastructure, application, logs, traces, user experience, synthetics, deployments, and incidents into a coherent operating view. - **Organisations improving SRE and service ownership:** Define services, teams, SLIs, SLOs, error budgets, monitors, runbooks, escalation, and incident communication. - **Companies controlling Datadog telemetry cost:** Optimise hosts, containers, custom metrics, log ingestion and indexing, trace sampling, retention, tags, and unused integrations. ### Implementation risks - **Datadog receives telemetry without a service model:** Hosts, containers, traces, logs, dashboards, monitors, teams, environments, and deployments cannot be connected reliably. - **Monitors generate noise without action ownership:** Thresholds, duplicates, missing context, weak routing, no runbooks, maintenance, dependencies, and stale resources increase alert fatigue. - **Telemetry cost grows through default collection:** Cardinality, logs, indexes, retention, APM sampling, custom metrics, containers, and integrations are not governed by value. ### Platform capabilities - Datadog organisation, account, integration, tag, service, team, environment, role, usage, and cost assessment - Infrastructure, cloud, Kubernetes, container, network, database, serverless, process, and integration monitoring - APM, distributed tracing, service maps, deployment tracking, profiling, error tracking, and OpenTelemetry integration - Log collection, pipelines, parsing, redaction, routing, archives, indexes, retention, sensitive data, and access controls - RUM, synthetics, browser, mobile, API, journey, frontend, and user-impact monitoring - Dashboards, notebooks, monitors, composite alerts, SLOs, error budgets, on-call, incidents, and post-incident workflows - Telemetry sampling, cardinality, retention, cost allocation, governance, automation, support, and managed observability ### Implementation system - **Service and telemetry model:** Services, teams, environments, versions, dependencies, tags, metrics, logs, traces, profiles, events, and deployments. - **Detection and objectives:** Monitors, anomaly and composite logic, SLIs, SLOs, error budgets, maintenance, routing, escalation, and runbooks. - **User and incident workflows:** RUM, synthetics, business journeys, incident declaration, responders, communication, evidence, timeline, and review. - **Datadog governance:** Roles, teams, integrations, API keys, data access, redaction, sampling, retention, usage, cost, automation, and lifecycle. ### Use cases - **Full-stack Datadog implementation:** Instrument cloud, Kubernetes, applications, databases, logs, traces, frontend, synthetics, services, dashboards, alerts, and incidents. - **Datadog SLO programme:** Define service ownership, user journeys, SLIs, objectives, error budgets, burn alerts, release use, review, and reporting. - **Datadog cost optimisation:** Analyse host and container scope, metrics, tags, logs, indexes, retention, traces, sampling, RUM, synthetics, and unused data. - **Monitoring and alert rationalisation:** Remove stale and duplicate alerts, align detection to user impact, improve routing and context, and establish monitor lifecycle ownership. ### Architecture - **Unified service tagging is foundational:** Apply consistent service, environment, version, team, region, tenant, and domain dimensions across every telemetry source. - **Logs and traces are governed before ingestion:** Filter, redact, sample, aggregate, route, retain, archive, and index according to investigation, security, compliance, and cost value. - **SLOs connect telemetry to operating decisions:** Use objectives and error budgets to guide alerts, incidents, capacity, releases, reliability work, and stakeholder reporting. ### Quality and governance - **Telemetry with ownership:** Metrics, logs, traces, profiles, events, entities, services, teams, environments, and deployments are consistently attributed. - **Actionable alerts and objectives:** Alerts, SLIs, SLOs, error budgets, escalation, runbooks, maintenance, and incident workflows are designed around user impact. - **Controlled telemetry economics:** Collection, sampling, cardinality, parsing, indexing, retention, access, sensitive data, and vendor cost are governed deliberately. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Datadog integration, telemetry, service, tag, monitor, role, usage, cost, and risk assessment - Service, instrumentation, log, trace, dashboard, alert, SLO, incident, and governance architecture - Production agents, integrations, OpenTelemetry, pipelines, dashboards, monitors, RUM, and synthetics - SLIs, SLOs, burn alerts, runbooks, routing, on-call, incident, and post-incident workflows - Sampling, parsing, redaction, retention, archive, access, cost, and lifecycle controls - Developer, SRE, operator, security, finance, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad reduce Datadog cost without losing critical visibility?** Yes. We classify telemetry by operational value and optimise collection, tags, custom metrics, logs, indexes, retention, trace sampling, hosts, containers, and synthetic coverage. - **Can Rokad implement Datadog with OpenTelemetry?** Yes. We design collectors, agents, protocols, resources, attributes, sampling, routing, correlation, backpressure, security, and ownership according to the telemetry architecture. - **Can existing Datadog monitors and dashboards be audited?** Yes. We review ownership, usage, duplication, stale resources, thresholds, routing, context, maintenance, service impact, tags, runbooks, and incident outcomes. - **Can Rokad operate Datadog continuously?** Yes. Managed scope can cover integrations, instrumentation, monitors, dashboards, SLOs, incidents, telemetry pipelines, access, usage, cost, and roadmap changes. --- ## [Platform service] Grafana observability services Canonical URL: https://rokad.co/en/services/cloud-devops/site-reliability-engineering/grafana Platform: Grafana > Rokad designs, implements, migrates, governs, and operates Grafana observability platforms across metrics, logs, traces, profiles, dashboards, alerts, and service objectives. Grafana can unify metrics, logs, traces, profiles, events, and data sources through open-source or managed architectures. Rokad designs collection, storage, tenancy, labels, dashboards, correlations, alerting, SLOs, access, retention, scaling, cost, upgrades, and operations around service and investigation workflows. ### Designed for - **Teams building an open observability stack:** Combine Grafana with suitable metrics, logs, traces, profiles, collectors, alerts, and storage under controlled ownership. - **Organisations adopting Grafana Cloud:** Design telemetry collection, access, usage, integrations, service modelling, alerting, SLOs, retention, and cost controls. - **Companies consolidating dashboards and alerting:** Standardise folders, teams, data sources, labels, templates, dashboards, alerts, correlations, runbooks, and lifecycle governance. ### Implementation risks - **Dashboards exist without a consistent telemetry model:** Labels, services, environments, data sources, variables, units, thresholds, and ownership differ across teams. - **Open-source components are deployed without platform operations:** Scaling, storage, retention, compaction, tenancy, upgrades, backup, security, query limits, and incident response are not owned. - **Metrics, logs, traces, and profiles cannot be correlated:** Resource attributes, labels, trace identifiers, exemplars, links, timestamps, and service metadata are inconsistent. ### Platform capabilities - Grafana OSS and Grafana Cloud architecture, tenancy, data source, access, usage, cost, migration, and operating assessment - Prometheus and compatible metrics, Loki logs, Tempo traces, profiling, OpenTelemetry, collectors, agents, and telemetry pipelines - Dashboards, variables, libraries, folders, teams, permissions, provisioning, versioning, annotations, and deployment tracking - Grafana Alerting, notification policies, contact points, silences, maintenance, multi-source alerts, runbooks, and escalation - Service and entity modelling, correlations, exemplars, links, RED and USE views, SLOs, error budgets, and investigations - Multi-tenancy, authentication, SSO, data-source credentials, network access, retention, quotas, limits, and sensitive data controls - High availability, scaling, storage, backup, upgrades, performance, query governance, cost, support, and managed operation ### Implementation system - **Telemetry pipeline:** Instrumentation, collectors, agents, receivers, processors, exporters, labels, resource attributes, sampling, routing, and security. - **Signal platforms:** Metrics, logs, traces, profiles, storage, tenancy, retention, scaling, compaction, query, backup, and lifecycle. - **Grafana experience:** Data sources, dashboards, correlations, Explore, alerts, SLOs, folders, teams, access, provisioning, and documentation. - **Observability operations:** Health, capacity, query performance, ingestion, cardinality, incidents, upgrades, cost, support, and platform roadmap. ### Use cases - **Grafana Cloud implementation:** Connect infrastructure, Kubernetes, applications, logs, traces, profiles, services, dashboards, alerts, objectives, and teams. - **Self-hosted observability platform:** Design and operate Grafana and selected signal backends with tenancy, scaling, storage, security, backup, and upgrades. - **OpenTelemetry and signal correlation:** Standardise resource attributes and identifiers so users can move between metrics, logs, traces, profiles, and deployments. - **Dashboard and alert governance:** Create reusable libraries, standards, provisioning, folders, permissions, ownership, testing, review, and retirement workflows. ### Architecture - **Telemetry identity is shared across signals:** Use consistent service, environment, version, instance, cluster, namespace, team, region, and trace attributes for correlation. - **Signal storage follows investigation value:** Select retention, resolution, sampling, indexing, labels, object storage, replicas, and query limits per signal and user need. - **Dashboards and alerts are provisioned assets:** Version critical resources, validate queries and data sources, review changes, preserve ownership, and promote across environments. ### Quality and governance - **Telemetry with ownership:** Metrics, logs, traces, profiles, events, entities, services, teams, environments, and deployments are consistently attributed. - **Actionable alerts and objectives:** Alerts, SLIs, SLOs, error budgets, escalation, runbooks, maintenance, and incident workflows are designed around user impact. - **Controlled telemetry economics:** Collection, sampling, cardinality, parsing, indexing, retention, access, sensitive data, and vendor cost are governed deliberately. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Grafana platform, telemetry, data source, dashboard, alert, access, usage, cost, and risk assessment - Collector, signal, tenancy, correlation, dashboard, alert, SLO, and operating architecture - Production Grafana, integrations, collectors, metrics, logs, traces, profiles, dashboards, and alerts - Service models, correlations, SLOs, error budgets, runbooks, routing, and incident workflows - Access, provisioning, retention, scaling, backup, upgrade, query, cost, and lifecycle controls - Developer, SRE, platform, security, operator, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad build a self-hosted Grafana observability platform?** Yes. We design signal backends, collectors, storage, tenancy, scaling, retention, authentication, network, backup, monitoring, upgrades, and support. - **Can Rokad implement Grafana Cloud with OpenTelemetry?** Yes. We configure SDKs, collectors, resource attributes, processing, sampling, routing, authentication, correlation, dashboards, alerts, and operating ownership. - **Can dashboards and alerts be stored in source control?** Yes. We can provision suitable resources through configuration or APIs, define environments and ownership, validate changes, and preserve controlled manual workflows where needed. - **Can Rokad migrate from another monitoring platform?** Yes. We inventory integrations, signals, queries, dashboards, alerts, SLOs, users, retention, cost, incidents, and operational dependencies before migration waves. --- ## [Platform service] New Relic observability services Canonical URL: https://rokad.co/en/services/cloud-devops/site-reliability-engineering/new-relic Platform: New Relic > Rokad implements, rationalises, governs, and operates New Relic across applications, infrastructure, logs, browser, mobile, synthetics, service levels, and incidents. New Relic can connect application performance, infrastructure, logs, browser and mobile experience, synthetic tests, alerts, service levels, and deployment changes. Rokad designs entity and service models, instrumentation, attributes, NRQL, dashboards, alert policies, SLOs, access, data governance, usage, cost, and operating workflows. ### Designed for - **Teams improving application and infrastructure visibility:** Instrument services, hosts, containers, Kubernetes, databases, logs, browser, mobile, synthetics, deployments, and dependencies. - **Organisations formalising service-level management:** Define entities, ownership, SLIs, SLOs, error budgets, burn alerts, runbooks, escalation, incidents, and reporting. - **Companies rationalising New Relic data and cost:** Control telemetry volume, attributes, logs, retention, sampling, agents, duplicate collection, queries, users, and unused resources. ### Implementation risks - **Entities and services are not consistently named:** Applications, hosts, Kubernetes, logs, browser, deployments, teams, environments, and dependencies cannot be correlated reliably. - **Alert policies focus on symptoms without user impact:** Thresholds, duplicates, evaluation windows, routing, muting, dependencies, runbooks, and service-level context create noise. - **Telemetry is ingested without data governance:** Sensitive attributes, log content, high-volume events, duplicate forwarding, retention, access, and cost are not controlled. ### Platform capabilities - New Relic organisation, account, entity, agent, integration, user, role, usage, cost, migration, and risk assessment - APM agents, distributed tracing, service maps, errors, deployments, profiling, code-level metrics, and OpenTelemetry integration - Infrastructure, cloud, Kubernetes, container, database, network, serverless, process, and integration monitoring - Log forwarding, parsing, attributes, correlation, sensitive data, routing, retention, access, and duplicate-ingestion control - Browser, mobile, frontend, synthetics, API, user journey, availability, and performance monitoring - NRQL, dashboards, workloads, alert policies, workflows, service levels, error budgets, incidents, and runbooks - Telemetry volume, sampling, attributes, access, cost allocation, automation, support, and managed New Relic operation ### Implementation system - **Entity and service model:** Applications, services, hosts, clusters, dependencies, teams, environments, versions, deployments, attributes, and ownership. - **Instrumentation and data:** Agents, OpenTelemetry, infrastructure, logs, browser, mobile, synthetics, events, attributes, sampling, and correlation. - **Detection and service levels:** NRQL, dashboards, alert conditions, policies, workflows, SLIs, SLOs, error budgets, runbooks, and escalation. - **New Relic governance:** Accounts, users, roles, data access, sensitive fields, retention, usage, cost, APIs, automation, support, and lifecycle. ### Use cases - **New Relic full-stack implementation:** Instrument applications, infrastructure, Kubernetes, databases, logs, browser, mobile, synthetics, services, dashboards, and alerts. - **New Relic APM modernisation:** Improve distributed tracing, service relationships, errors, deployments, logs in context, attributes, sampling, and performance investigations. - **Service-level and alert programme:** Create user-centred SLIs, SLOs, burn alerts, policies, workflows, runbooks, on-call routing, review, and reporting. - **New Relic data and cost optimisation:** Review agents, events, attributes, logs, duplicate forwarding, browser, synthetics, queries, users, retention, and operational value. ### Architecture - **Entity identity is consistent across telemetry:** Standardise service, application, environment, version, team, cluster, namespace, host, deployment, and trace attributes. - **NRQL becomes a governed analytical interface:** Version critical queries, define units and windows, reuse business and service semantics, document ownership, and validate data changes. - **Service levels guide alert and release decisions:** Use objectives and error budgets to connect user impact, reliability work, capacity, incidents, deployments, and stakeholder reporting. ### Quality and governance - **Telemetry with ownership:** Metrics, logs, traces, profiles, events, entities, services, teams, environments, and deployments are consistently attributed. - **Actionable alerts and objectives:** Alerts, SLIs, SLOs, error budgets, escalation, runbooks, maintenance, and incident workflows are designed around user impact. - **Controlled telemetry economics:** Collection, sampling, cardinality, parsing, indexing, retention, access, sensitive data, and vendor cost are governed deliberately. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - New Relic entity, agent, integration, telemetry, alert, access, usage, cost, and risk assessment - Service, instrumentation, log, trace, dashboard, alert, SLO, and governance architecture - Production agents, integrations, OpenTelemetry, logs, browser, synthetics, dashboards, and alerts - NRQL libraries, service levels, error budgets, runbooks, workflows, escalation, and incident controls - Attribute, sampling, sensitive data, retention, access, usage, cost, and lifecycle controls - Developer, SRE, operator, security, finance, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad implement New Relic with OpenTelemetry?** Yes. We design SDK and collector architecture, resources, attributes, sampling, routing, authentication, correlation, dashboards, alerts, and ownership. - **Can existing New Relic alerts and dashboards be audited?** Yes. We review usage, ownership, stale resources, NRQL, thresholds, windows, routing, context, runbooks, service impact, duplication, and incident outcomes. - **Can Rokad reduce New Relic data ingestion and cost?** Yes. We classify telemetry by value and optimise agents, events, attributes, logs, duplicate forwarding, trace sampling, browser, synthetics, retention, and access. - **Can Rokad migrate from Datadog or another platform?** Yes. We inventory integrations, instrumentation, telemetry, queries, dashboards, alerts, service levels, users, retention, cost, and incident dependencies before migration. --- ## [Service] Data engineering Canonical URL: https://rokad.co/en/services/data-engineering > Reliable data systems that turn operational sources into governed, testable, discoverable, and decision-ready information. Rokad builds data pipelines, platforms, warehouses, lakehouse systems, transformation layers, semantic models, business intelligence, data quality, lineage, and operational controls. The focus is trusted data products that support applications, analytics, AI, reporting, and organisational decisions. ### Capabilities - Data-source discovery, contracts, ingestion, CDC, streaming, and batch pipelines - Cloud data platforms, lakehouse, warehouse, storage, orchestration, and compute - Transformation, modelling, semantic layers, metrics, and analytics engineering - Data quality, testing, observability, lineage, catalogue, access, and governance - Business intelligence, dashboards, self-service, and operational reporting - Migration, performance, cost, reliability, documentation, and managed data operations ### Challenges - **Reports disagree because data meaning is inconsistent:** Teams calculate the same metric differently across spreadsheets, applications, dashboards, and departments. - **Pipelines fail without clear ownership or evidence:** Schema changes, late data, duplicates, missing records, and source outages are discovered after decisions are affected. - **Data volume grows faster than trust and usability:** More storage and tools do not create discoverable, governed, understandable, and decision-ready information. ### Service scope - **Data discovery and architecture:** Map sources, consumers, semantics, quality, access, latency, retention, volume, risk, and target data products. - **Platform and pipeline delivery:** Build ingestion, storage, orchestration, transformation, modelling, testing, observability, and access foundations. - **Adoption and operation:** Deliver metrics, dashboards, documentation, ownership, service controls, cost management, and continuous data-quality improvement. ### Use cases - **Create a trusted reporting foundation:** Consolidate operational data into governed models and metrics used consistently across leadership and teams. - **Build application and AI data pipelines:** Deliver fresh, validated, traceable data for product features, machine learning, search, and automation. - **Modernise a legacy warehouse or ETL estate:** Improve reliability, transparency, performance, cost, testing, deployment, and maintainability without losing reporting continuity. - **Enable self-service analytics:** Give authorised users discoverable, documented, governed data and metrics without uncontrolled spreadsheet duplication. ### Delivery process - **Discover:** Clarify objectives, users, systems, data, constraints, dependencies, risk, and measurable acceptance criteria. - **Architect:** Define the target system, operating model, security controls, migration sequence, and ownership before implementation. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish production ownership, service controls, measurement, support, and a continuous improvement backlog. ### Engineering standards - **Secure by design:** Identity, permissions, secrets, networks, data boundaries, dependencies, change controls, and recovery are addressed throughout delivery. - **Observable operation:** Metrics, logs, traces, data quality, costs, failures, capacity, and service outcomes are made visible and actionable. - **Automated and reproducible:** Infrastructure, pipelines, configuration, tests, deployment, and recovery procedures are versioned and repeatable wherever practical. ### Deliverables - Data landscape, requirements, and quality assessment - Target data architecture and platform decision records - Production ingestion, transformation, orchestration, and serving pipelines - Warehouse, lakehouse, semantic model, and metric definitions - Data tests, observability, lineage, catalogue, access, and governance controls - Dashboards, documentation, runbooks, ownership, and operating plan ### Engagement models - **Assessment and roadmap:** A bounded current-state review, target architecture, prioritised risks, and executable transformation plan. - **Fixed-scope implementation:** A defined platform, migration, pipeline, or reliability outcome with explicit milestones and acceptance criteria. - **Embedded platform team:** Specialists working with internal engineering, data, security, and operations teams over an evolving roadmap. - **Managed operation:** Ongoing ownership of production infrastructure, data platforms, reliability, security, cost, and improvement. ### Frequently asked questions - **Can Rokad work with our current warehouse and BI tools?** Yes. We assess existing sources, pipelines, warehouse, transformation, reporting, governance, skills, cost, and operational constraints before recommending change. - **Do we need a data lake, warehouse, or lakehouse?** The choice depends on workloads, data types, latency, governance, skills, interoperability, performance, and cost. We select the simplest architecture that meets the operating requirements. - **How do you improve data trust?** We combine clear ownership, contracts, tested transformations, lineage, observability, semantic definitions, access controls, documentation, and visible incident handling. - **Can Rokad manage the data platform after launch?** Yes. Managed data operations can cover pipelines, orchestration, quality, incidents, performance, cost, access, schema changes, documentation, and continuous improvement. --- ## [Service specialisation] Data pipeline development Canonical URL: https://rokad.co/en/services/data-engineering/data-pipelines > Rokad develops reliable batch and streaming data pipelines with explicit contracts, testing, observability, lineage, recovery, and operational ownership. A production data pipeline must deliver the right data, at the required freshness, with visible quality and recoverable failure behaviour. Rokad builds ingestion, change-data-capture, event, file, API, transformation, orchestration, and serving pipelines for analytics, applications, AI, and operational workflows. ### Designed for - **Teams consolidating operational data:** Move records from applications, vendors, files, devices, and databases into governed analytical or operational systems. - **Product and AI teams requiring dependable data:** Deliver fresh, validated, traceable data for models, search, recommendations, reporting, and product features. - **Organisations replacing fragile ETL jobs:** Introduce orchestration, tests, lineage, retries, backfills, alerts, and ownership around existing data movement. ### Challenges - **Failures are discovered by report users:** Source outages, schema changes, duplicates, late data, partial loads, and silent transformations lack operational visibility. - **Backfills and reprocessing are unsafe:** Pipelines are not idempotent, partition-aware, versioned, or designed to reproduce historical output consistently. - **Source and consumer expectations are implicit:** Schemas, semantics, freshness, completeness, ordering, retention, and ownership change without contracts or coordination. ### Capabilities - Source discovery, schemas, contracts, ownership, and data classification - API, database, file, event, SaaS, device, and partner ingestion - Batch, micro-batch, streaming, CDC, queue, and event-driven pipelines - Orchestration, scheduling, dependencies, retries, backfills, and idempotency - Validation, reconciliation, tests, lineage, observability, and incident handling - Transformation, enrichment, deduplication, partitioning, and serving - Performance, cost, security, documentation, and managed pipeline operation ### Solution components - **Source contract:** Schema, semantics, change process, freshness, completeness, access, ownership, and expected failure behaviour. - **Pipeline runtime:** Connectors, jobs, streams, queues, orchestration, checkpoints, retries, backfills, state, and resource controls. - **Quality and lineage:** Validation, reconciliation, tests, anomalies, source-to-output traceability, incidents, and impact analysis. - **Data delivery:** Tables, files, APIs, topics, features, indexes, models, service levels, access, and consumer documentation. ### Use cases - **Operational data ingestion:** Replicate application and vendor data into a warehouse, lakehouse, search, or downstream operational system. - **Real-time event pipeline:** Process events for monitoring, fraud, recommendations, product features, alerts, or operational decision support. - **AI and feature pipeline:** Prepare consistent training and inference data with timestamps, validation, lineage, and reproducibility. - **Legacy ETL modernisation:** Replace scripts and opaque jobs with versioned transformations, orchestration, tests, observability, and managed deployment. ### Architecture and integration - **Delivery semantics:** Define ordering, duplication, lateness, exactly-once assumptions, idempotency, checkpoints, and reconciliation per consumer. - **Schema evolution:** Version contracts, detect breaking changes, preserve compatibility, quarantine invalid records, and coordinate producers and consumers. - **Reprocessing as a designed path:** Retain source evidence and versioned logic so historical partitions or events can be rebuilt safely and compared. ### Quality and control - **Trust through contracts:** Ownership, schemas, semantics, freshness, completeness, access, and failure expectations are explicit between producers and consumers. - **Tested transformation:** Pipelines and models include validation, reconciliation, lineage, observability, and controlled change before decision use. - **Governed access:** Identity, classification, least privilege, retention, masking, audit, and usage boundaries follow the sensitivity of the data. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Source, consumer, contract, quality, and latency assessment - Pipeline architecture, orchestration, storage, and delivery design - Production batch, streaming, CDC, or event pipelines - Validation, reconciliation, tests, lineage, and observability controls - Backfill, retry, recovery, deployment, and incident workflows - Data contracts, runbooks, ownership, and consumer documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Should a pipeline be batch or real time?** The decision depends on business latency, source behaviour, consumer needs, operational complexity, cost, ordering, and recovery. Many systems use a deliberate combination. - **How do you handle source schema changes?** We define contracts, detect changes, classify compatibility, validate records, quarantine failures, version transformations, communicate impact, and coordinate rollout. - **Can Rokad modernise existing ETL without replacing everything?** Yes. We can introduce orchestration, tests, observability, contracts, and deployment incrementally while migrating pipelines by value and risk. - **Can pipelines be managed after launch?** Yes. Managed support can cover failures, backfills, schema changes, quality incidents, performance, cost, access, upgrades, and new sources or consumers. --- ## [Platform service] Airbyte data integration services Canonical URL: https://rokad.co/en/services/data-engineering/data-pipelines/airbyte Platform: Airbyte > Rokad implements, extends, migrates, and operates Airbyte data integration across managed or self-hosted deployments, standard connectors, custom connectors, CDC, and governed pipelines. Airbyte provides an extensible data movement platform with a broad connector ecosystem and custom connector tooling. Rokad designs the deployment, sources, destinations, connection modes, schemas, state, CDC, custom connectors, orchestration, validation, monitoring, recovery, security, and operating model required for dependable production replication. ### Designed for - **Data teams consolidating SaaS and database ingestion:** Move operational data into warehouses, lakehouses, lakes, databases, and analytical platforms through managed and custom connectors. - **Organisations requiring self-managed data movement:** Operate Airbyte in controlled cloud, private, or hybrid infrastructure with explicit networking, secrets, storage, upgrades, and support. - **Teams integrating unsupported or private systems:** Develop connectors through Connector Builder or the Connector Development Kit with tested schemas, state, pagination, and error handling. ### Implementation risks - **Connector success does not guarantee data completeness:** Schema drift, deleted records, incremental cursors, API limits, source changes, type conversion, and destination behaviour create silent gaps. - **Self-hosting transfers platform responsibility:** Control plane, workers, database, object storage, networking, secrets, logs, upgrades, capacity, backup, and recovery require ownership. - **Custom connectors are built without lifecycle controls:** Authentication, streams, schemas, state, pagination, rate limits, tests, releases, compatibility, and support are not maintained systematically. ### Platform capabilities - Airbyte Cloud and self-managed suitability, architecture, deployment, migration, workload, security, usage, and cost assessment - Source, destination, connection, stream, sync mode, cursor, primary key, schema, namespace, and refresh design - Database CDC, log-based replication, incremental append, deduplication, full refresh, deletion, and history strategies - Connector Builder, low-code connectors, Connector Development Kit, private APIs, custom sources, destinations, and connector testing - Warehouse, lakehouse, object storage, database, SaaS, API, file, and operational destination integration - Orchestration through Airbyte APIs, Terraform, suitable schedulers, dbt or transformation handoff, environment, and deployment workflows - Validation, reconciliation, alerts, logs, metrics, schema change, retries, backfills, upgrades, security, and managed operation ### Implementation system - **Airbyte platform:** Cloud or self-managed control plane, workers, database, object storage, networking, secrets, identities, upgrades, backup, and capacity. - **Connector estate:** Standard and custom sources and destinations, authentication, streams, schemas, state, pagination, rate limits, versions, and tests. - **Replication contracts:** Sync modes, cursors, primary keys, history, deletion, namespace, type mapping, destination tables, freshness, and reconciliation. - **Pipeline operations:** Schedules, jobs, failures, logs, alerts, schema changes, retries, backfills, usage, cost, incidents, ownership, and support. ### Use cases - **SaaS-to-warehouse ingestion:** Replicate customer, sales, marketing, support, finance, commerce, and operational data into governed analytical storage. - **Database CDC pipeline:** Capture source changes into a warehouse or lakehouse with explicit snapshot, checkpoint, deletion, schema, lag, and recovery behaviour. - **Custom private API connector:** Implement authentication, discovery, streams, pagination, incremental state, rate limits, error handling, tests, and connector release workflows. - **Airbyte self-hosted platform:** Deploy and operate Airbyte with controlled cloud infrastructure, networks, storage, secrets, observability, backups, upgrades, and support. ### Architecture - **Replication state is a production asset:** Protect cursors, CDC offsets, snapshots, checkpoints, connection configuration, connector versions, and source identifiers through backup and change control. - **Raw replicated data remains distinguishable from transformed models:** Separate source-faithful ingestion, normalisation, business transformation, semantic models, retention, and consumer ownership. - **Connector upgrades are data changes:** Review schema, state, field, type, naming, deletion, performance, and destination effects before promoting connector versions. ### Quality and governance - **Reliable replication semantics:** Schema changes, ordering, duplication, deletion, checkpoints, retries, backfills, idempotency, and reconciliation are designed per source and consumer. - **Secure source-to-destination path:** Credentials, network access, encryption, sensitive fields, logs, connectors, destinations, and operator permissions are controlled. - **Observable pipeline operation:** Sync state, lag, throughput, failures, records, schema drift, cost, incidents, and ownership remain visible and actionable. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Airbyte deployment, connector, source, destination, schema, security, usage, cost, and risk assessment - Platform, network, connector, replication, schema, orchestration, and operating architecture - Production Airbyte deployment, workspaces, sources, destinations, connections, and infrastructure automation - Connector Builder or CDK connectors, tests, releases, documentation, and private integrations - Validation, reconciliation, monitoring, schema-change, retry, backfill, backup, upgrade, and recovery controls - Data, developer, administrator, security, operator, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad build custom Airbyte connectors?** Yes. We can use Connector Builder, low-code definitions, or the Connector Development Kit to implement authentication, streams, discovery, schemas, pagination, state, rate limits, errors, tests, and releases. - **Can Rokad self-host Airbyte?** Yes. We design infrastructure, networking, database, object storage, secrets, workers, scaling, observability, backups, upgrades, security, and operating procedures. - **Can Airbyte capture database changes?** For supported databases and configurations, yes. We assess source logs, permissions, snapshot behaviour, offsets, schema changes, deletions, lag, retention, failover, and recovery. - **Can Rokad migrate pipelines from Fivetran or custom scripts?** Yes. We inventory sources, schemas, history, cursors, transformations, destinations, schedules, failures, costs, validation, and reporting dependencies before migration. --- ## [Platform service] Fivetran data integration services Canonical URL: https://rokad.co/en/services/data-engineering/data-pipelines/fivetran Platform: Fivetran > Rokad implements, migrates, governs, optimises, and operates Fivetran data pipelines across managed connectors, database replication, custom connectors, transformations, and destinations. Fivetran automates connector operation and source-schema handling for managed data movement. Production success still depends on connector and destination architecture, historical sync planning, CDC prerequisites, schema governance, transformations, validation, access, reliability, usage, cost, and downstream ownership. Rokad designs and operates these responsibilities around the data product. ### Designed for - **Data teams prioritising managed connector operations:** Replicate SaaS, database, event, file, and application data without operating a general connector runtime directly. - **Enterprises standardising governed ingestion:** Control groups, destinations, connectors, users, roles, private networking, schemas, transformations, usage, and support. - **Organisations rationalising Fivetran spend and pipeline value:** Align active rows or other usage drivers, sync frequency, schemas, history, connector scope, destinations, and ownership with business need. ### Implementation risks - **Initial historical syncs are underestimated:** Source load, destination storage, row volume, schema size, API limits, replication logs, maintenance windows, and validation affect migration. - **Automated schema handling surprises consumers:** New columns, tables, types, deletes, re-syncs, naming, history modes, and connector updates alter downstream transformations and reports. - **Connector usage grows without data-product ownership:** Unused schemas, high-volume tables, frequent syncs, duplicate sources, stale pipelines, and historical retention increase spend and complexity. ### Platform capabilities - Fivetran account, group, destination, connector, source, schema, security, usage, cost, migration, and risk assessment - SaaS, database, file, event, application, private, and hybrid-deployment connector configuration - Database replication, CDC prerequisites, historical sync, incremental updates, deletes, re-sync, failover, lag, and recovery - Connector SDK and function connector development for private or unsupported APIs and event sources - Warehouse, lakehouse, lake, database, and supported destination architecture, networking, credentials, and data lifecycle - Transformations, dbt integration, scheduling, dependencies, schema change, validation, lineage, and downstream handoff - Roles, groups, secrets, private networking, monitoring, alerts, usage, cost, incident response, and managed operation ### Implementation system - **Fivetran organisation model:** Accounts, groups, destinations, connectors, users, roles, identities, networks, credentials, policies, usage, and budgets. - **Connector and replication contracts:** Sources, schemas, tables, columns, history, cursors, CDC, deletion, frequency, resync, naming, destination, and ownership. - **Transformation and consumption:** Raw schemas, dbt models, transformations, dependencies, schedules, tests, lineage, semantic models, and consumer service levels. - **Fivetran operations:** Syncs, failures, warnings, lag, schema changes, usage, cost, connector updates, incidents, support, and lifecycle reviews. ### Use cases - **Managed SaaS ingestion estate:** Deliver customer, marketing, revenue, support, finance, commerce, and operational sources into governed analytical storage. - **Database replication to warehouse or lakehouse:** Configure log-based or supported replication with snapshot, history, deletion, schema, lag, failover, and validation controls. - **Fivetran connector SDK integration:** Build custom extraction logic, schemas, state, authentication, pagination, rate handling, deployment, tests, monitoring, and support. - **Fivetran usage and cost optimisation:** Review active schemas and tables, row changes, sync frequencies, duplicate sources, re-syncs, destinations, ownership, and business value. ### Architecture - **Groups and destinations reflect security and operating boundaries:** Separate regions, environments, business domains, data classes, networks, warehouses, budgets, and support ownership where required. - **Schema evolution is governed downstream:** Detect and classify changes, quarantine or stage where needed, test transformations, communicate impact, and preserve contract ownership. - **Usage economics are designed at connector and table level:** Control selected objects, frequency, history, re-syncs, destination patterns, duplicate ingestion, retention, and cost allocation. ### Quality and governance - **Reliable replication semantics:** Schema changes, ordering, duplication, deletion, checkpoints, retries, backfills, idempotency, and reconciliation are designed per source and consumer. - **Secure source-to-destination path:** Credentials, network access, encryption, sensitive fields, logs, connectors, destinations, and operator permissions are controlled. - **Observable pipeline operation:** Sync state, lag, throughput, failures, records, schema drift, cost, incidents, and ownership remain visible and actionable. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Fivetran organisation, connector, source, schema, destination, security, usage, cost, and risk assessment - Group, destination, connector, replication, transformation, validation, and operating architecture - Production groups, destinations, connectors, schemas, networking, credentials, and infrastructure automation - Connector SDK integrations, dbt transformation workflows, tests, lineage, and consumer handoff - Monitoring, reconciliation, schema-change, re-sync, recovery, usage, cost, incident, and lifecycle controls - Data, developer, administrator, security, finance, operator, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad implement Fivetran database replication?** Yes. We assess database version, logs, permissions, network, snapshot, CDC, schemas, deletes, history, failover, source impact, destination design, and validation. - **Can Rokad build custom Fivetran connectors?** Yes. We can use supported connector-development capabilities to implement authentication, schemas, incremental state, pagination, API limits, errors, deployment, tests, and monitoring. - **Can Rokad optimise Fivetran cost?** Yes. We review connector scope, schemas, tables, update volume, history, frequencies, re-syncs, duplicate ingestion, destinations, ownership, and downstream value. - **Can Rokad migrate from another ingestion platform to Fivetran?** Yes. We map sources, schemas, history, state, transformations, destinations, schedules, quality, costs, reporting dependencies, cutover, and reconciliation. --- ## [Platform service] Apache Kafka engineering services Canonical URL: https://rokad.co/en/services/data-engineering/data-pipelines/apache-kafka Platform: Apache Kafka > Rokad designs, builds, migrates, secures, and operates Apache Kafka and compatible managed event-streaming platforms across applications, data pipelines, and real-time systems. Kafka is a distributed event log and streaming backbone, not merely a message queue. Rokad defines event ownership, topic and partition design, schemas, producers, consumers, delivery semantics, Kafka Connect, stream processing, security, capacity, observability, disaster recovery, platform lifecycle, and team operating contracts. ### Designed for - **Product teams adopting event-driven architecture:** Decouple services, publish domain events, coordinate workflows, build projections, and preserve replayable operational history. - **Data teams building real-time pipelines:** Capture database changes, ingest events, process streams, validate schemas, route data, and deliver analytical or operational consumers. - **Enterprises stabilising Kafka estates:** Improve cluster architecture, capacity, security, schemas, connectors, lag, incidents, upgrades, recovery, cost, and ownership. ### Implementation risks - **Topics are created without domain ownership or contracts:** Names, keys, schemas, retention, partitions, ordering, compatibility, sensitivity, consumers, and lifecycle are undocumented. - **Consumer lag is treated as one infrastructure metric:** Backlog age, partition skew, processing time, errors, rebalances, dependencies, capacity, and business impact are not distinguished. - **Exactly-once language hides end-to-end side effects:** Broker transactions do not automatically make databases, APIs, files, emails, or downstream systems idempotent and recoverable. ### Platform capabilities - Kafka use-case, event, workload, deployment, managed-provider, region, capacity, security, cost, and operating assessment - Cluster, broker, controller, rack or zone, storage, network, listener, replication, availability, scaling, and lifecycle architecture - Topic, partition, key, ordering, retention, compaction, replication, quota, naming, ownership, and data classification design - Producer, consumer group, offset, retry, dead-letter, idempotency, transaction, replay, backpressure, and failure engineering - Schema registry, Avro, Protobuf, JSON Schema, compatibility, evolution, validation, catalogue, lineage, and governance - Kafka Connect, source and sink connectors, CDC, custom connectors, stream processing, Kafka Streams, Flink, or compatible engines - Authentication, authorisation, encryption, secrets, observability, lag, capacity, upgrades, disaster recovery, incidents, and managed operation ### Implementation system - **Kafka platform:** Managed or self-managed clusters, brokers, controllers, storage, zones, networks, identities, security, quotas, upgrades, and capacity. - **Event contracts:** Domains, topics, keys, partitions, ordering, schemas, compatibility, retention, compaction, sensitivity, ownership, and service levels. - **Processing and integration:** Producers, consumers, offsets, retries, dead letters, Connect, CDC, stream processing, state, replay, idempotency, and reconciliation. - **Kafka operations:** Broker health, under-replication, lag, throughput, latency, storage, quotas, rebalances, incidents, recovery, cost, and support. ### Use cases - **Event-driven application architecture:** Publish durable domain events, decouple services, build consumers and projections, coordinate processes, and support replay and recovery. - **Database CDC and real-time data platform:** Capture operational changes, apply schemas, transform streams, route consumers, preserve lineage, and monitor lag and quality. - **Kafka cluster migration:** Move from self-managed or another provider through topic, schema, producer, consumer, connector, replication, cutover, and rollback planning. - **Kafka reliability and capacity programme:** Improve partitions, replication, storage, quotas, producers, consumers, lag, observability, upgrades, recovery, and ownership. ### Architecture - **Partition key is a domain and scaling decision:** Choose keys from ordering, entity affinity, distribution, hot-key risk, consumer parallelism, replay, and future growth requirements. - **Schemas evolve under explicit compatibility policy:** Define producer and consumer rollout, defaults, required fields, semantic changes, validation, ownership, and deprecation—not only syntax compatibility. - **End-to-end processing remains idempotent and reconcilable:** Track event identifiers, offsets, transactions, external side effects, retries, duplicates, checkpoints, replay, and business reconciliation. ### Quality and governance - **Reliable replication semantics:** Schema changes, ordering, duplication, deletion, checkpoints, retries, backfills, idempotency, and reconciliation are designed per source and consumer. - **Secure source-to-destination path:** Credentials, network access, encryption, sensitive fields, logs, connectors, destinations, and operator permissions are controlled. - **Observable pipeline operation:** Sync state, lag, throughput, failures, records, schema drift, cost, incidents, and ownership remain visible and actionable. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Kafka use-case, event, topic, schema, producer, consumer, cluster, security, capacity, cost, and risk assessment - Cluster, topic, schema, integration, processing, security, recovery, and operating architecture - Production clusters or managed services, topics, schemas, ACLs, quotas, and infrastructure automation - Producers, consumers, Connect, CDC, custom connectors, stream processing, retry, and replay implementation - Monitoring, lag, capacity, security, upgrade, backup or replication, disaster-recovery, and incident controls - Developer, data, platform, security, operator, governance, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Should we self-manage Kafka or use a managed service?** We compare control, regions, networking, security, integrations, service guarantees, support, data movement, skills, lifecycle effort, portability, and total cost. - **Can Rokad design Kafka topic and schema standards?** Yes. We define domains, naming, ownership, keys, partitions, retention, compaction, schemas, compatibility, sensitivity, service levels, evolution, and deprecation. - **Can Rokad migrate an existing Kafka cluster?** Yes. We inventory topics, schemas, producers, consumers, connectors, offsets, throughput, security, retention, dependencies, downtime, replication, validation, and rollback. - **Can Rokad operate Kafka after launch?** Yes. Managed scope can cover cluster health, topics, schemas, connectors, lag, capacity, storage, security, upgrades, incidents, recovery, cost, and platform evolution. --- ## [Service specialisation] Data platform engineering Canonical URL: https://rokad.co/en/services/data-engineering/data-platforms > Rokad designs and builds governed data platforms that provide reliable ingestion, storage, compute, transformation, discovery, access, quality, and operations. A data platform is the shared operating system for data producers, engineers, analysts, applications, and AI teams. Rokad designs cloud and hybrid platforms around workload requirements, ownership, access, data products, interoperability, reliability, cost, and developer experience. ### Designed for - **Organisations building a shared data foundation:** Consolidate fragmented pipelines, storage, warehouses, tooling, permissions, and operational practices. - **Data teams scaling beyond project-specific infrastructure:** Provide reusable ingestion, transformation, quality, catalogue, access, and observability capabilities. - **Companies enabling analytics and AI together:** Support reporting, exploration, machine learning, retrieval, applications, and governed data exchange on one coherent foundation. ### Challenges - **Every team assembles its own data stack:** Tools, storage, schemas, security, quality, deployment, and monitoring diverge, increasing cost and reducing trust. - **The platform stores data but does not make it usable:** Ownership, semantics, documentation, quality, lineage, access, and consumer interfaces remain unclear. - **Cloud data cost grows without accountability:** Compute, storage, movement, retention, inefficient queries, duplicate copies, and idle resources lack measurement and ownership. ### Capabilities - Data-platform strategy, workload assessment, and target architecture - Lake, lakehouse, warehouse, object, stream, catalogue, and metadata foundations - Ingestion, orchestration, transformation, notebook, feature, and serving services - Identity, access, classification, encryption, masking, retention, and audit - Data quality, contracts, lineage, observability, incident, and ownership systems - Developer environments, templates, CI/CD, infrastructure code, and self-service - Performance, capacity, cost, backup, recovery, governance, and managed operation ### Solution components - **Storage and compute plane:** Object, warehouse, lakehouse, stream, query, processing, isolation, scale, performance, and lifecycle. - **Data control plane:** Catalogue, metadata, lineage, ownership, classification, access, policy, quality, contracts, and audit. - **Engineering platform:** Repositories, environments, orchestration, tests, deployment, templates, observability, documentation, and self-service. - **Consumer interfaces:** Tables, semantic models, APIs, files, features, streams, dashboards, notebooks, search, and data products. ### Use cases - **Cloud data-platform implementation:** Create secure accounts, storage, compute, orchestration, governance, access, observability, and delivery foundations. - **Lakehouse or warehouse modernisation:** Move from fragmented or legacy systems to a more reliable, interoperable, governed, and cost-controlled platform. - **Enterprise data-product platform:** Enable domains to publish owned, documented, tested, discoverable, and supported datasets and interfaces. - **AI-ready data foundation:** Support training, inference, features, retrieval, evaluation, lineage, and governed access to operational evidence. ### Architecture and integration - **Workload-driven platform choice:** Select warehouse, lakehouse, streaming, query, catalogue, and orchestration capabilities from actual latency, scale, skill, and governance needs. - **Separation with interoperability:** Separate storage, compute, metadata, orchestration, and serving where useful while preserving open contracts and portable data. - **Platform as a product:** Define users, supported paths, service levels, documentation, telemetry, cost, support, roadmap, and deprecation for platform capabilities. ### Quality and control - **Trust through contracts:** Ownership, schemas, semantics, freshness, completeness, access, and failure expectations are explicit between producers and consumers. - **Tested transformation:** Pipelines and models include validation, reconciliation, lineage, observability, and controlled change before decision use. - **Governed access:** Identity, classification, least privilege, retention, masking, audit, and usage boundaries follow the sensitivity of the data. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Data-platform workload, tooling, governance, and cost assessment - Target platform, storage, compute, metadata, security, and operating architecture - Infrastructure code, environments, orchestration, access, and shared services - Catalogue, lineage, quality, observability, policy, and ownership implementation - Developer templates, CI/CD, self-service, cost, and support controls - Runbooks, platform documentation, governance, and handover plan ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Do we need a data lakehouse?** Not automatically. We compare warehouse, lakehouse, lake, operational store, streaming, and managed-service options against workloads, skills, interoperability, governance, performance, and cost. - **Can Rokad build on our existing cloud?** Yes. We can use current cloud, identity, network, security, CI/CD, and data services where they meet the target requirements. - **How do you prevent a data platform becoming a dumping ground?** We define ownership, contracts, lifecycle, quality, catalogue, access, retention, cost, and consumer interfaces rather than measuring success by data volume alone. - **Can the platform support multiple business units?** Yes. We can design domain, account, project, workspace, catalogue, access, compute, cost, and service boundaries for shared governance with delegated ownership. --- ## [Platform service] Snowflake data platform services Canonical URL: https://rokad.co/en/services/data-engineering/data-platforms/snowflake Platform: Snowflake > Rokad designs, builds, migrates, governs, optimises, and operates Snowflake data platforms for analytics, data products, applications, and AI workloads. Snowflake separates storage from elastic compute and provides managed data, sharing, governance, and pipeline capabilities. Rokad structures accounts, databases, schemas, warehouses, roles, ingestion, transformations, dynamic tables or streams and tasks, data quality, security, observability, performance, cost, and release operations around owned data products. ### Designed for - **Organisations building a governed Snowflake foundation:** Create account, environment, database, warehouse, role, ingestion, transformation, security, observability, and cost standards. - **Teams migrating from legacy warehouses or fragmented lakes:** Move data and workloads while redesigning schemas, pipelines, security, performance, validation, and reporting continuity. - **Companies controlling Snowflake performance and spend:** Connect warehouse sizing, concurrency, queries, clustering, storage, refresh, retention, workloads, and ownership to business value. ### Implementation risks - **Warehouses are created without workload boundaries:** ETL, BI, data science, applications, and ad hoc users compete for compute, concurrency, budgets, and service expectations. - **Role hierarchy and object ownership are difficult to audit:** Users, functional roles, access roles, future grants, databases, shares, masking, and service identities evolve inconsistently. - **Data pipelines mix several execution models without ownership:** Loads, Snowpipe, dynamic tables, streams, tasks, procedures, dbt, and external orchestration duplicate transformations and recovery logic. ### Platform capabilities - Snowflake organisation, account, region, environment, database, schema, warehouse, role, workload, usage, and cost assessment - Virtual warehouses, multi-cluster concurrency, resource monitors, workload isolation, sizing, auto-suspend, scaling, and performance - Batch, Snowpipe, streaming, connectors, stages, file formats, COPY, CDC, ingestion, validation, and reconciliation - Dynamic tables, streams, tasks, procedures, Snowpark, dbt, orchestration, dependency, freshness, retry, and backfill design - Role-based access, object ownership, network policy, encryption, masking, row access, classification, audit, and secure sharing - Dimensional, domain, data-vault, semantic, feature, application, sharing, and data-product modelling - Query optimisation, clustering, caching, storage, retention, observability, deployment, cost, governance, and managed operation ### Implementation system - **Snowflake account foundation:** Accounts, environments, regions, databases, schemas, warehouses, roles, integrations, policies, budgets, and shared services. - **Data movement and transformation:** Stages, connectors, loads, Snowpipe, streams, tasks, dynamic tables, dbt, Snowpark, orchestration, validation, and recovery. - **Data products and consumption:** Warehouse models, semantic datasets, shares, applications, APIs, features, notebooks, BI, ownership, contracts, and service levels. - **Snowflake operations:** Queries, warehouses, failures, freshness, access, audit, retention, security, performance, spend, releases, support, and roadmap. ### Use cases - **Snowflake platform implementation:** Establish environments, warehouses, roles, databases, ingestion, transformations, governance, observability, CI/CD, and operating procedures. - **Warehouse migration to Snowflake:** Move schemas, data, pipelines, procedures, reports, security, history, workloads, and operations through validated migration waves. - **Snowflake pipeline modernisation:** Select and implement dynamic tables, streams and tasks, dbt, Snowpark, or external orchestration according to workload behaviour. - **Snowflake performance and cost programme:** Optimise warehouse isolation, sizing, concurrency, queries, clustering, refresh, retention, data movement, and chargeback ownership. ### Architecture - **Warehouses represent workload and service boundaries:** Separate ingestion, transformation, BI, data science, applications, and ad hoc use where concurrency, priority, budget, or ownership differ. - **Dynamic tables are chosen by declarative freshness needs:** Compare dynamic tables with streams and tasks, dbt, materialized views, and external orchestration using latency, logic, recovery, and cost. - **Role hierarchy separates access from business function:** Design account roles, database roles or access roles, functional roles, service identities, ownership, future grants, and exception review deliberately. ### Quality and governance - **Governed data boundaries:** Catalogues, schemas, workspaces, projects, domains, identity, classification, policy, lineage, audit, and ownership are explicit. - **Tested and observable data:** Contracts, freshness, completeness, validity, reconciliation, lineage, failures, backfills, and consumer impact are measurable. - **Workload and cost isolation:** Compute, storage, concurrency, priority, scaling, quotas, budgets, retention, and workload ownership protect performance and economics. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Snowflake account, workload, data, pipeline, role, security, performance, usage, and cost assessment - Account, warehouse, database, ingestion, transformation, governance, and operating architecture - Production databases, schemas, warehouses, roles, integrations, policies, and infrastructure automation - Ingestion, dynamic-table, stream, task, dbt, Snowpark, sharing, and data-product implementation - Testing, lineage, monitoring, performance, security, cost, deployment, and recovery controls - Data, developer, administrator, governance, operator, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Should Snowflake transformations use dynamic tables, streams and tasks, or dbt?** The choice depends on SQL and procedural logic, freshness, dependencies, incremental behaviour, testing, lineage, developer workflow, backfills, operational control, and cost. Mixed architectures are common. - **Can Rokad migrate an existing warehouse to Snowflake?** Yes. We assess schemas, data types, history, procedures, pipelines, reports, security, performance, costs, dependencies, cutover, and reconciliation before migration waves. - **Can Rokad improve Snowflake cost and performance?** Yes. We analyse warehouse sizing and isolation, queries, concurrency, clustering, refresh, storage, retention, data transfer, usage, ownership, and resource monitors. - **Can Rokad operate Snowflake after launch?** Yes. Managed services can cover pipelines, freshness, quality, queries, warehouses, roles, access, security, incidents, performance, spend, releases, and new data products. --- ## [Platform service] Databricks lakehouse engineering services Canonical URL: https://rokad.co/en/services/data-engineering/data-platforms/databricks Platform: Databricks > Rokad designs, builds, migrates, governs, and operates Databricks lakehouse platforms across data engineering, analytics, machine learning, and AI. Databricks combines lakehouse storage, Spark processing, SQL analytics, orchestration, governance, data science, machine learning, and AI. Rokad designs account and workspace boundaries, cloud storage, Unity Catalog, Delta or Iceberg tables, Lakeflow pipelines and jobs, SQL warehouses, identity, CI/CD, observability, cost, and lifecycle operations. ### Designed for - **Data and AI teams creating one governed lakehouse:** Support ingestion, engineering, SQL, BI, data science, machine learning, retrieval, and AI assets under shared governance. - **Organisations migrating Spark, Hadoop, lake, or warehouse workloads:** Move data and processing while redesigning storage, catalogues, pipelines, compute, security, quality, and operational ownership. - **Companies standardising multiple Databricks workspaces:** Align accounts, workspaces, metastores, catalogues, identity, clusters, serverless compute, network, deployment, cost, and governance. ### Implementation risks - **Workspaces become isolated project environments:** Storage, catalogues, identities, libraries, clusters, notebooks, jobs, secrets, policies, and data ownership diverge. - **Compute choices do not match workload economics:** Interactive, jobs, SQL, serverless, shared, dedicated, autoscaling, photon, instance, and cluster policies are selected inconsistently. - **Notebook delivery bypasses software engineering controls:** Source, dependencies, tests, environments, data contracts, deployment, lineage, monitoring, and rollback remain informal. ### Platform capabilities - Databricks account, workspace, cloud, network, identity, metastore, catalogue, compute, workload, usage, and cost assessment - Unity Catalog, catalogues, schemas, managed, external and foreign tables, volumes, lineage, permissions, audit, sharing, and governance - Delta Lake and supported open table formats, medallion or domain design, optimisation, retention, change data, and data quality - Lakeflow ingestion, declarative pipelines, jobs, workflows, orchestration, streaming, batch, retries, backfills, and observability - SQL warehouses, data modelling, semantic and BI integration, performance, concurrency, serverless, and workload isolation - Notebooks, repositories, packages, environments, tests, CI/CD, Databricks Asset Bundles, APIs, infrastructure code, and release workflows - Data science, MLflow, feature and model assets, vector and AI workloads, security, cost, support, and managed operation ### Implementation system - **Lakehouse foundation:** Accounts, workspaces, cloud storage, networks, identity, Unity Catalog, catalogues, schemas, tables, volumes, and policies. - **Engineering and orchestration:** Lakeflow, jobs, notebooks, packages, streaming, batch, dependencies, tests, data quality, lineage, retries, and backfills. - **Analytics and AI workloads:** SQL warehouses, BI, data science, MLflow, feature, model, vector, application, and AI assets with governed access. - **Databricks operations:** Compute, policies, jobs, pipelines, freshness, quality, permissions, security, performance, cost, releases, incidents, and support. ### Use cases - **Enterprise Databricks lakehouse:** Establish cloud, workspace, Unity Catalog, storage, compute, ingestion, transformation, SQL, ML, governance, and operations. - **Legacy data-platform migration:** Move Spark, Hadoop, warehouse, ETL, lake, notebook, and machine-learning workloads with validation and continuity. - **Databricks data-engineering platform:** Build reusable ingestion, Lakeflow, testing, quality, lineage, orchestration, deployment, observability, and developer workflows. - **Unified analytics and AI foundation:** Connect governed tables and features to SQL, BI, notebooks, models, retrieval, agents, evaluation, and applications. ### Architecture - **Unity Catalog defines the governance boundary:** Design metastores, workspaces, catalogues, schemas, storage, identities, privileges, lineage, audit, and ownership before workload migration. - **Compute is isolated by workload and trust:** Select serverless, SQL, job, interactive, shared, dedicated, GPU, and policy controls from performance, data, security, and cost requirements. - **Notebook exploration and production delivery are separated:** Move reusable logic into versioned modules, pipelines, jobs, tests, assets, environments, and deployment workflows while preserving exploration. ### Quality and governance - **Governed data boundaries:** Catalogues, schemas, workspaces, projects, domains, identity, classification, policy, lineage, audit, and ownership are explicit. - **Tested and observable data:** Contracts, freshness, completeness, validity, reconciliation, lineage, failures, backfills, and consumer impact are measurable. - **Workload and cost isolation:** Compute, storage, concurrency, priority, scaling, quotas, budgets, retention, and workload ownership protect performance and economics. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Databricks account, workspace, storage, catalogue, compute, pipeline, security, usage, and cost assessment - Lakehouse, Unity Catalog, data, compute, pipeline, analytics, AI, and operating architecture - Cloud and Databricks infrastructure, workspaces, catalogues, storage, policies, and shared services - Lakeflow pipelines, jobs, notebooks, packages, SQL warehouses, models, ML, or AI assets - Testing, lineage, monitoring, security, performance, cost, CI/CD, backup, and recovery controls - Data, developer, ML, administrator, governance, operator, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad implement Unity Catalog for existing workspaces?** Yes. We assess metastores, workspaces, storage, tables, identities, permissions, jobs, clusters, lineage, sharing, and migration constraints before staged adoption. - **Can Rokad migrate Spark or Hadoop workloads to Databricks?** Yes. We map data, formats, jobs, libraries, schedules, clusters, dependencies, security, performance, costs, tests, and cutover requirements. - **Can Databricks support both BI and AI workloads?** Yes. We design shared governance and data assets with workload-specific SQL, engineering, data science, model, vector, application, compute, and service boundaries. - **Can Rokad manage Databricks after launch?** Yes. Managed scope can include pipelines, jobs, compute, SQL, data quality, catalogues, permissions, security, performance, cost, releases, incidents, and new data products. --- ## [Platform service] Microsoft Fabric implementation services Canonical URL: https://rokad.co/en/services/data-engineering/data-platforms/microsoft-fabric Platform: Microsoft Fabric > Rokad designs, implements, migrates, governs, and operates Microsoft Fabric data platforms across engineering, warehousing, real-time analytics, and Power BI. Microsoft Fabric provides a SaaS analytics environment spanning OneLake, lakehouse, warehouse, Data Factory, real-time workloads, data science, semantic models, and Power BI. Rokad designs tenant, capacity, workspace, domain, data, identity, pipeline, model, deployment, security, monitoring, cost, and support boundaries around the organisation's operating model. ### Designed for - **Microsoft organisations consolidating analytics tooling:** Connect Azure and enterprise data with Fabric engineering, warehousing, real-time, semantic models, Power BI, identity, and governance. - **Power BI teams expanding into a governed data platform:** Introduce OneLake, lakehouse or warehouse, Data Factory, Direct Lake, domains, deployment, quality, lineage, and platform operations. - **Enterprises migrating data workloads into Fabric:** Move pipelines, lakes, warehouses, reports, semantic models, security, history, and operational workflows with continuity. ### Implementation risks - **Fabric capacity is shared without workload governance:** Engineering, warehouse, refresh, report, real-time, data science, and interactive use compete for capacity and service expectations. - **Workspaces mirror teams but not data ownership:** Domains, environments, lakehouses, warehouses, semantic models, reports, pipelines, permissions, and support boundaries diverge. - **Power BI assets and upstream data delivery evolve separately:** Model changes, Direct Lake, pipelines, data quality, lineage, deployment, refresh, and report compatibility are not coordinated. ### Platform capabilities - Fabric tenant, capacity, domain, workspace, OneLake, item, identity, licence, usage, cost, and governance assessment - Lakehouse, Warehouse, SQL endpoints, shortcuts, medallion and domain models, OneLake organisation, and data lifecycle - Data Factory pipelines, Dataflow Gen2, connectors, notebooks, Spark, ingestion, orchestration, transformations, retries, and backfills - Real-Time Intelligence, event ingestion, streaming, KQL databases, event processing, alerting, and operational analytics - Power BI semantic models, Direct Lake, import and DirectQuery decisions, measures, security, reports, apps, and embedded scenarios - Microsoft Entra, workspace roles, item permissions, data access, sensitivity, lineage, audit, gateways, private connectivity, and governance - Git integration, deployment pipelines, CI/CD, environments, monitoring, capacity, performance, cost, support, and managed operation ### Implementation system - **Fabric tenant and capacity foundation:** Tenant settings, capacities, domains, workspaces, identities, roles, gateways, networks, policies, licences, budgets, and support. - **OneLake data architecture:** Lakehouses, warehouses, shortcuts, files, tables, schemas, SQL endpoints, domains, ownership, retention, quality, and lineage. - **Engineering and analytical delivery:** Pipelines, dataflows, notebooks, Spark, real-time, transformations, semantic models, Direct Lake, reports, and applications. - **Fabric lifecycle operations:** Git, deployments, environments, refresh, capacity, quality, access, audit, performance, cost, incidents, and support. ### Use cases - **Enterprise Microsoft Fabric foundation:** Establish tenant, capacity, domain, workspace, OneLake, identity, governance, deployment, monitoring, and support controls. - **Power BI and data-platform consolidation:** Connect upstream ingestion and modelling with semantic layers, Direct Lake, reports, apps, security, lineage, and release workflows. - **Fabric lakehouse or warehouse implementation:** Build ingestion, storage, transformation, SQL, quality, lineage, semantic, BI, data-science, and operational processes. - **Microsoft data-estate migration:** Move Azure Data Factory, Synapse, Power BI, lakes, warehouses, pipelines, reports, and models through validated waves where suitable. ### Architecture - **Capacity is a shared service with workload ownership:** Define placement, scale, priorities, refresh, concurrency, monitoring, chargeback, incident, and exception procedures for each workload class. - **Workspace and domain boundaries are designed separately:** Use domains for business ownership and discovery, while workspaces carry environment, team, item, deployment, access, and lifecycle boundaries. - **Semantic models are production data products:** Version measures, relationships, security, metadata, deployment, refresh, Direct Lake behaviour, tests, documentation, and ownership. ### Quality and governance - **Governed data boundaries:** Catalogues, schemas, workspaces, projects, domains, identity, classification, policy, lineage, audit, and ownership are explicit. - **Tested and observable data:** Contracts, freshness, completeness, validity, reconciliation, lineage, failures, backfills, and consumer impact are measurable. - **Workload and cost isolation:** Compute, storage, concurrency, priority, scaling, quotas, budgets, retention, and workload ownership protect performance and economics. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Fabric tenant, capacity, workspace, data, pipeline, semantic, licence, usage, cost, and risk assessment - Tenant, domain, workspace, OneLake, engineering, warehouse, BI, governance, and operating architecture - Production capacities, workspaces, lakehouses, warehouses, shortcuts, pipelines, dataflows, and notebooks - Semantic models, Direct Lake, reports, apps, real-time, gateways, and enterprise integrations - Git, deployment, testing, lineage, security, monitoring, performance, capacity, and cost controls - Data, BI, developer, administrator, governance, operator, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Should Microsoft Fabric use a lakehouse, warehouse, or both?** The decision depends on data types, SQL needs, engineering, BI, interoperability, transaction and governance expectations, skills, performance, and cost. Combined patterns are common. - **Can Rokad migrate Power BI and Azure data workloads into Fabric?** Yes. We assess pipelines, gateways, lakes, warehouses, models, measures, reports, security, refresh, capacities, licences, history, and compatibility before migration. - **Can Rokad implement Fabric deployment pipelines and Git integration?** Yes. We design workspaces, branches, item support, parameters, dependencies, promotion, validation, permissions, rollback, and release evidence. - **Can Rokad manage Fabric capacities and operations?** Yes. Managed scope can cover capacity, pipelines, refresh, quality, models, reports, permissions, gateways, monitoring, performance, cost, incidents, and platform changes. --- ## [Service specialisation] Data warehousing Canonical URL: https://rokad.co/en/services/data-engineering/data-warehousing > Rokad designs, builds, migrates, and optimises data warehouses that provide governed historical information, consistent metrics, and reliable analytical performance. A useful warehouse organises data around decisions, history, business meaning, and repeatable consumption. Rokad builds ingestion, staging, transformation, dimensional or domain models, semantic layers, quality, performance, security, migration, and reporting foundations. ### Designed for - **Organisations consolidating reporting data:** Create one governed analytical foundation across applications, finance, sales, operations, customers, and external sources. - **Teams modernising a legacy warehouse:** Improve reliability, deployment, testing, performance, cost, documentation, lineage, and cloud integration. - **Companies replacing spreadsheet reporting:** Establish controlled historical models and metric definitions that support dashboards and self-service analysis. ### Challenges - **The warehouse mirrors source systems rather than business questions:** Consumers must reconstruct relationships, history, status, and metric logic independently in every report. - **Historical changes are lost or misrepresented:** Customer, product, organisation, pricing, and operational attributes change without explicit history and effective-date modelling. - **Performance improvements create uncontrolled complexity:** Copies, extracts, aggregates, materialisations, and caches proliferate without ownership, lineage, or lifecycle. ### Capabilities - Warehouse requirements, source, consumer, history, and metric assessment - Cloud, on-premises, columnar, lakehouse, and hybrid warehouse architecture - Staging, integration, dimensional, Data Vault, domain, and semantic modelling - Incremental loads, CDC, history, late data, reconciliation, and backfills - Transformation tests, documentation, lineage, quality, and governance - Partitioning, clustering, materialisation, workload, query, and cost optimisation - Warehouse migration, reporting continuity, security, and managed operation ### Solution components - **Source and staging layer:** Faithful ingestion, timestamps, history, raw evidence, schema changes, quality, and replay capability. - **Integrated business model:** Conformed entities, facts, dimensions, domains, relationships, effective dates, and shared business definitions. - **Serving and semantic layer:** Metrics, aggregates, marts, permissions, performance, discoverability, documentation, and BI consumption. - **Warehouse operation:** Loads, freshness, quality, incidents, performance, capacity, cost, access, schema changes, and lifecycle. ### Use cases - **Enterprise reporting warehouse:** Consolidate finance, customer, sales, product, operations, and service data into consistent historical models. - **Cloud warehouse migration:** Move schema, history, transformations, schedules, security, and reports with reconciliation and continuity controls. - **Customer and product analytics foundation:** Model journeys, cohorts, usage, revenue, retention, subscriptions, support, and product behaviour consistently. - **Regulatory or audit reporting:** Create traceable historical transformations, evidence, access, retention, reconciliation, and controlled report outputs. ### Architecture and integration - **History by requirement:** Choose snapshot, event, slowly changing, transaction, or effective-dated patterns based on the questions and evidence required. - **Business grain first:** Define what one row represents, keys, events, measures, dimensions, and timing before designing tables or dashboards. - **Reconciliation across layers:** Compare source, staging, integrated, semantic, and report outputs so transformation errors are visible and explainable. ### Quality and control - **Trust through contracts:** Ownership, schemas, semantics, freshness, completeness, access, and failure expectations are explicit between producers and consumers. - **Tested transformation:** Pipelines and models include validation, reconciliation, lineage, observability, and controlled change before decision use. - **Governed access:** Identity, classification, least privilege, retention, masking, audit, and usage boundaries follow the sensitivity of the data. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Warehouse source, history, metric, consumer, and quality assessment - Target warehouse, model, security, performance, and migration architecture - Production ingestion, staging, transformation, and warehouse models - Semantic layers, marts, metrics, documentation, and BI interfaces - Tests, reconciliation, lineage, observability, and access controls - Migration, performance, cost, runbook, and operating documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Should we use dimensional modelling or another approach?** The choice depends on source volatility, history, governance, consumer needs, team skills, auditability, and platform. We may combine raw, integrated, domain, dimensional, and semantic layers. - **Can you migrate an existing warehouse without breaking reports?** Yes. We inventory consumers, map schemas and logic, run systems in parallel, reconcile outputs, validate performance, and phase report migration with rollback options. - **How do you manage metric consistency?** We define grain, filters, timing, status, dimensions, ownership, tests, documentation, and semantic models so important metrics have controlled definitions. - **Can Rokad improve warehouse performance and cost?** Yes. We analyse workload, scans, joins, partitions, clustering, materialisations, concurrency, caching, schedules, storage, retention, and ownership before optimisation. --- ## [Platform service] Google BigQuery engineering services Canonical URL: https://rokad.co/en/services/data-engineering/data-warehousing/bigquery Platform: Google BigQuery > Rokad designs, builds, migrates, governs, optimises, and operates BigQuery analytical platforms and data warehouses on Google Cloud. BigQuery separates managed storage and compute for serverless analytical workloads. Rokad designs projects, datasets, regions, tables, partitioning, clustering, ingestion, transformations, reservations and slots, identity, policy, quality, lineage, BI, performance, cost, and release operations around governed analytical products. ### Designed for - **Google Cloud teams building analytical foundations:** Create project, dataset, ingestion, warehouse, security, semantic, BI, governance, observability, and cost standards. - **Organisations migrating legacy or cloud warehouses:** Move schemas, data, queries, pipelines, reports, permissions, history, performance, and operations with validated continuity. - **Companies improving BigQuery performance and spend:** Optimise scans, partitions, clusters, materialisation, slots, reservations, workloads, storage, retention, and ownership. ### Implementation risks - **Projects and datasets lack domain and environment boundaries:** Ownership, regions, access, billing, retention, lineage, service accounts, and support are inconsistent. - **Queries scan more data than the decision requires:** Table design, partition filters, clustering, transformations, materialisation, BI models, and user behaviour drive avoidable cost and latency. - **Serverless operation hides workload contention and accountability:** Interactive, scheduled, ingestion, BI, data science, and application workloads lack reservation, priority, budget, and service ownership. ### Platform capabilities - Google Cloud project, region, dataset, table, workload, reservation, identity, security, usage, and cost assessment - Dataset, table, partition, cluster, materialized view, external and federated data, retention, and lifecycle architecture - Batch and streaming ingestion, transfers, Storage Write API, Pub/Sub integration, CDC, validation, and reconciliation - SQL transformation, Dataform or dbt, scheduled queries, orchestration, dependency, testing, backfill, and deployment - IAM, service accounts, authorised views, row and column security, masking, encryption, policy tags, audit, and governance - Reservations, editions, slots, workload management, query optimisation, BI Engine, caching, monitoring, and cost controls - Looker and BI integration, semantic models, data products, sharing, applications, incidents, support, and managed operation ### Implementation system - **BigQuery warehouse foundation:** Projects, regions, datasets, tables, storage, reservations, identities, policies, budgets, logs, and shared services. - **Ingestion and transformation:** Batch, streaming, transfers, CDC, files, SQL models, orchestration, tests, quality, lineage, retries, and backfills. - **Analytical products:** Domain and dimensional models, semantic datasets, metrics, Looker, Power BI, Tableau, applications, sharing, and service levels. - **BigQuery operations:** Queries, slots, reservations, failures, freshness, access, performance, security, storage, cost, releases, and support. ### Use cases - **BigQuery data warehouse implementation:** Build project, dataset, ingestion, transformation, modelling, security, BI, observability, deployment, and operating foundations. - **Warehouse migration to BigQuery:** Translate schemas, SQL, procedures, data, pipelines, reports, security, and performance through rehearsed migration waves. - **Real-time analytical pipeline:** Ingest events through suitable streaming paths, validate and model data, expose low-latency analytics, and operate freshness and cost. - **BigQuery performance and cost programme:** Improve partitions, clusters, query patterns, materialisation, reservations, slots, BI, retention, storage, and workload ownership. ### Architecture - **Project, dataset, and table boundaries carry different concerns:** Use projects for billing and broad policy, datasets for regional access and ownership, and tables for lifecycle and model contracts. - **Partitioning and clustering follow dominant query patterns:** Design pruning, cardinality, ingestion, update, retention, and maintenance around observed workloads rather than defaults. - **Reservations provide explicit workload economics:** Separate or prioritise critical BI, transformation, data science, application, and ad hoc workloads according to service and budget needs. ### Quality and governance - **Governed data boundaries:** Catalogues, schemas, workspaces, projects, domains, identity, classification, policy, lineage, audit, and ownership are explicit. - **Tested and observable data:** Contracts, freshness, completeness, validity, reconciliation, lineage, failures, backfills, and consumer impact are measurable. - **Workload and cost isolation:** Compute, storage, concurrency, priority, scaling, quotas, budgets, retention, and workload ownership protect performance and economics. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - BigQuery project, dataset, workload, pipeline, identity, security, performance, usage, and cost assessment - Warehouse, ingestion, transformation, reservation, governance, BI, and operating architecture - Production projects, datasets, tables, reservations, roles, policies, and infrastructure automation - Ingestion, streaming, SQL, Dataform or dbt, semantic, BI, and data-product implementation - Testing, lineage, monitoring, security, performance, cost, deployment, and recovery controls - Data, developer, administrator, governance, operator, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad migrate another warehouse to BigQuery?** Yes. We assess SQL, data types, procedures, data volumes, history, pipelines, reports, security, performance, costs, dependencies, and cutover before migration. - **Should BigQuery use on-demand pricing or reservations?** The decision depends on query patterns, concurrency, predictability, workload isolation, service objectives, commitments, governance, and cost. Hybrid approaches may be appropriate. - **Can Rokad improve BigQuery query cost?** Yes. We analyse scanned data, partitions, clusters, SQL, materialisation, BI models, reservations, caching, retention, storage, user behaviour, and ownership. - **Can Rokad manage BigQuery continuously?** Yes. Managed scope can include pipelines, models, quality, freshness, access, security, reservations, performance, cost, incidents, deployments, and new analytical products. --- ## [Platform service] Amazon Redshift engineering services Canonical URL: https://rokad.co/en/services/data-engineering/data-warehousing/amazon-redshift Platform: Amazon Redshift > Rokad designs, builds, migrates, governs, optimises, and operates Amazon Redshift analytical warehouses on AWS. Amazon Redshift supports provisioned and serverless warehouse models integrated with S3, AWS identity, data movement, governance, and analytical tools. Rokad designs namespaces or clusters, databases, schemas, workload management, ingestion, Spectrum, modelling, security, sharing, monitoring, performance, cost, backup, recovery, and deployment around owned analytical workloads. ### Designed for - **AWS organisations building an analytical warehouse:** Create Redshift, S3, ingestion, transformation, security, BI, governance, observability, backup, and cost foundations. - **Teams migrating legacy warehouses into AWS:** Move schemas, data, SQL, procedures, pipelines, reports, permissions, history, performance, and operations through controlled waves. - **Companies modernising existing Redshift clusters:** Evaluate RA3, Serverless, Spectrum, workload management, scaling, table design, vacuum, statistics, monitoring, and cost. ### Implementation risks - **Provisioned and Serverless choices do not match workloads:** Concurrency, predictability, control, isolation, pause patterns, scaling, networking, and cost assumptions are not measured. - **Table and workload design creates performance variability:** Distribution, sort keys, compression, skew, statistics, maintenance, queues, locks, queries, and data growth are unmanaged. - **S3 and Redshift data ownership is unclear:** Spectrum, lake tables, warehouse tables, copies, partitions, catalogues, security, retention, and authoritative models overlap. ### Platform capabilities - Redshift provisioned and Serverless assessment, architecture, sizing, migration, workload, usage, and cost analysis - Clusters, namespaces, workgroups, databases, schemas, RA3, managed storage, networking, parameter, and maintenance design - S3, COPY, streaming, zero-ETL and suitable integration patterns, CDC, ingestion, validation, and reconciliation - SQL transformation, dbt, stored procedures, orchestration, dependency, testing, backfill, deployment, and data quality - Distribution, sort, compression, materialized views, Spectrum, query optimisation, statistics, vacuum, concurrency, and workload management - IAM, roles, network, encryption, secrets, row and column security, data sharing, Lake Formation or Glue integration, audit, and governance - CloudWatch, system tables, advisor evidence, backup, snapshots, recovery, scaling, performance, cost, incidents, and managed operation ### Implementation system - **Redshift warehouse foundation:** AWS accounts, regions, clusters or workgroups, databases, schemas, networks, identity, encryption, budgets, logs, and shared services. - **Ingestion and modelling:** S3, files, streams, CDC, copies, transformations, dbt, procedures, orchestration, tests, quality, retries, and backfills. - **Workload and data products:** Distribution, sort, Spectrum, materialisation, WLM, semantic models, BI, sharing, applications, ownership, and service levels. - **Redshift operations:** Queries, queues, storage, failures, freshness, access, maintenance, backup, security, performance, cost, releases, and support. ### Use cases - **Amazon Redshift implementation:** Build provisioned or Serverless warehouse, ingestion, transformation, modelling, security, BI, monitoring, backup, and operations. - **Warehouse migration to Redshift:** Translate schemas, SQL, procedures, data, pipelines, reports, security, history, and performance through rehearsed waves. - **Redshift modernisation:** Evaluate RA3 or Serverless, redesign tables and WLM, integrate S3, improve queries, automate maintenance, and establish cost ownership. - **AWS lake and warehouse analytics:** Connect S3, Glue or suitable catalogues, Spectrum, Redshift tables, sharing, transformations, BI, governance, and data-product boundaries. ### Architecture - **Provisioned and Serverless are workload decisions:** Compare control, predictability, concurrency, networking, isolation, elasticity, maintenance, operational effort, and cost using real usage. - **Distribution and sort design follow data relationships:** Model joins, filters, skew, data volume, update patterns, concurrency, maintenance, and future growth before selecting physical design. - **Warehouse and lake authority are explicit:** Define which data is mastered, transformed, shared, retained, secured, and queried in Redshift, S3, and connected systems. ### Quality and governance - **Governed data boundaries:** Catalogues, schemas, workspaces, projects, domains, identity, classification, policy, lineage, audit, and ownership are explicit. - **Tested and observable data:** Contracts, freshness, completeness, validity, reconciliation, lineage, failures, backfills, and consumer impact are measurable. - **Workload and cost isolation:** Compute, storage, concurrency, priority, scaling, quotas, budgets, retention, and workload ownership protect performance and economics. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Redshift cluster or Serverless, workload, data, pipeline, security, performance, usage, and cost assessment - Warehouse, ingestion, S3, transformation, physical, WLM, governance, BI, and operating architecture - Production clusters or workgroups, databases, schemas, roles, policies, networks, and infrastructure automation - Ingestion, Spectrum, SQL, dbt, procedure, semantic, BI, sharing, and data-product implementation - Testing, monitoring, backup, recovery, security, performance, cost, deployment, and maintenance controls - Data, developer, administrator, governance, operator, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Should we use Redshift Serverless or a provisioned cluster?** We compare workload predictability, concurrency, networking, feature and control needs, maintenance, scaling, isolation, operating effort, and cost before recommending a model. - **Can Rokad migrate an existing warehouse to Redshift?** Yes. We assess data types, SQL, procedures, data volumes, history, pipelines, reports, security, performance, costs, dependencies, and cutover before migration waves. - **Can Rokad improve a slow Redshift warehouse?** Yes. We analyse table distribution and sort, skew, compression, statistics, vacuum, queries, locks, WLM, materialisation, Spectrum, concurrency, storage, and workload behaviour. - **Can Rokad manage Redshift continuously?** Yes. Managed services can cover pipelines, models, quality, freshness, access, maintenance, snapshots, security, performance, cost, incidents, releases, and new analytical products. --- ## [Service specialisation] Business intelligence Canonical URL: https://rokad.co/en/services/data-engineering/business-intelligence > Rokad develops business-intelligence systems that connect governed metrics and data models with dashboards, reporting, self-service analysis, and operational decisions. Business intelligence succeeds when information is trustworthy, understandable, timely, and connected to action. Rokad designs metric systems, semantic models, dashboards, scheduled reporting, exploratory analysis, alerts, governance, access, and adoption around real decision workflows. ### Designed for - **Leadership teams requiring consistent performance views:** Create shared definitions and decision-ready reporting across revenue, operations, customers, product, finance, and risk. - **Operational teams replacing manual reporting:** Automate recurring analysis, exceptions, alerts, drill-down, and workflow context from governed sources. - **Data teams enabling controlled self-service:** Provide documented semantic models and access without allowing metric logic to fragment across spreadsheets. ### Challenges - **Dashboards display numbers without decision context:** Users cannot understand definitions, drivers, thresholds, ownership, actions, or uncertainty behind the visualisation. - **Different teams report different versions of truth:** Filters, timing, statuses, joins, exclusions, and dimensions are recreated independently in every dashboard. - **Reporting demand overwhelms the data team:** Consumers lack safe models, documentation, reusable metrics, discovery, and skills for controlled self-service. ### Capabilities - Decision, audience, metric, reporting, and adoption discovery - Metric definitions, ownership, dimensions, hierarchies, and semantic models - Executive, operational, analytical, customer, and embedded dashboards - Scheduled reports, alerts, subscriptions, exports, and narrative reporting - Drill-down, exploration, self-service, row-level access, and governance - Data quality, freshness, lineage, documentation, usage, and trust indicators - BI migration, performance, tool evaluation, training, and managed improvement ### Solution components - **Metric system:** Definitions, grain, dimensions, status, time, targets, thresholds, owners, tests, and change control. - **Semantic and access layer:** Reusable models, relationships, permissions, row security, calculations, documentation, and query behaviour. - **Decision experience:** Dashboards, reports, alerts, annotations, drill-down, comparisons, explanations, and workflow actions. - **BI operations:** Freshness, failures, performance, usage, content lifecycle, ownership, training, support, and governance. ### Use cases - **Executive performance system:** Connect strategic objectives with governed financial, customer, operational, product, and risk indicators. - **Operational command dashboards:** Surface workload, exceptions, service levels, delays, quality, capacity, and actions for daily operations. - **Customer and product analytics:** Understand acquisition, journeys, usage, conversion, retention, revenue, support, and segment behaviour. - **Embedded analytics:** Provide authorised customers or partners with contextual dashboards and reports inside a product or portal. ### Architecture and integration - **Semantic logic outside visualisations:** Centralise important definitions and relationships so dashboards consume governed meaning instead of recreating it. - **Progressive disclosure:** Begin with decision-level signals and allow users to drill into drivers, segments, records, and evidence without clutter. - **Freshness and trust visible to users:** Expose update time, quality status, ownership, definitions, caveats, and lineage where decisions depend on them. ### Quality and control - **Trust through contracts:** Ownership, schemas, semantics, freshness, completeness, access, and failure expectations are explicit between producers and consumers. - **Tested transformation:** Pipelines and models include validation, reconciliation, lineage, observability, and controlled change before decision use. - **Governed access:** Identity, classification, least privilege, retention, masking, audit, and usage boundaries follow the sensitivity of the data. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Decision, audience, metric, dashboard, and BI estate assessment - Metric catalogue, semantic model, access, and governance design - Production dashboards, reports, alerts, and embedded analytics - Row-level security, calculations, documentation, and self-service models - Freshness, quality, performance, usage, and content-lifecycle controls - Training, support, ownership, governance, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Can Rokad work with our existing BI tool?** Yes. We can improve Power BI, Tableau, Looker, Metabase, Superset, cloud-native tools, or other supported platforms before recommending replacement. - **How do you stop dashboard sprawl?** We introduce ownership, semantic reuse, certification, naming, collections, lifecycle, usage review, archival, templates, and a controlled request process. - **Can users analyse data themselves?** Yes. We provide documented models, governed dimensions and metrics, appropriate access, examples, training, and usage monitoring rather than unrestricted raw-table access. - **Can BI be embedded into our software product?** Yes. We can use native embedding, APIs, custom visualisations, semantic services, tenant controls, row security, caching, and product-specific interfaces. --- ## [Platform service] Power BI development and governance services Canonical URL: https://rokad.co/en/services/data-engineering/business-intelligence/power-bi Platform: Microsoft Power BI > Rokad designs, builds, migrates, governs, and operates Power BI semantic models, reports, apps, gateways, security, deployment pipelines, and analytical workflows. Power BI delivers governed analysis when semantic models, measures, relationships, security, refresh, Direct Lake or query modes, workspaces, reports, apps, deployment, lineage, capacity, and ownership are designed together. Rokad engineers that complete lifecycle across Power BI and Microsoft Fabric environments. ### Designed for - **Organisations building trusted management reporting:** Create shared semantic models, measures, dimensions, reports, dashboards, apps, subscriptions, permissions, and decision workflows. - **Enterprises consolidating uncontrolled Power BI estates:** Rationalise workspaces, datasets, semantic models, duplicate measures, reports, gateways, refresh, licences, capacities, and access. - **Microsoft Fabric teams implementing end-to-end analytics:** Connect OneLake, lakehouses, warehouses, Direct Lake, semantic models, reports, deployment pipelines, governance, and capacity operations. ### Implementation risks - **Reports calculate the same metric differently:** Measures, filters, calendars, currency, status, relationships, and business rules are duplicated across files and models. - **Semantic models are not treated as production assets:** DAX, relationships, refresh, security, metadata, performance, deployment, compatibility, and ownership lack controlled lifecycle practices. - **Capacity and refresh failures affect users unpredictably:** Queries, Direct Lake, imports, gateways, dataflows, background operations, concurrency, memory, and workload placement are not governed. ### Platform capabilities - Power BI tenant, workspace, capacity, licence, semantic model, report, gateway, role, usage, migration, and governance assessment - Star schemas, relationships, calculation groups, DAX measures, dimensions, hierarchies, metadata, perspectives, and semantic contracts - Import, DirectQuery, composite, Direct Lake, aggregation, incremental refresh, partition, model-size, and performance architecture - Reports, dashboards, drill, tooltips, bookmarks, navigation, mobile layouts, accessibility, subscriptions, alerts, and apps - Row-level and object-level security, Microsoft Entra groups, workspace roles, sharing, sensitivity, audit, external access, and governance - Gateways, dataflows, Fabric, Azure, SQL, APIs, files, cloud applications, refresh, credentials, and enterprise integration - Git and source workflows where supported, deployment pipelines, environments, testing, monitoring, capacity, support, and managed BI operation ### Implementation system - **Power BI semantic layer:** Business entities, star schemas, relationships, measures, calculation groups, time, currency, security, metadata, and ownership. - **Report and app experience:** Visual design, navigation, drill, filters, tooltips, accessibility, mobile, subscriptions, alerts, apps, and user guidance. - **Data and refresh system:** Sources, gateways, dataflows, Fabric, import, DirectQuery, Direct Lake, refresh, incremental processing, credentials, and failure recovery. - **Power BI operations:** Tenants, workspaces, capacities, deployments, access, usage, refresh, performance, incidents, cost, adoption, and lifecycle. ### Use cases - **Executive and operational reporting platform:** Deliver governed financial, sales, customer, product, service, workforce, operational, and strategic reporting from shared definitions. - **Power BI semantic-model programme:** Consolidate duplicate datasets and measures into reusable models with security, documentation, testing, performance, and ownership. - **Power BI and Fabric implementation:** Connect lakehouse or warehouse data through Direct Lake or other suitable modes into semantic models, reports, apps, and governance. - **Power BI estate modernisation:** Inventory assets, remove duplication, improve models and DAX, rationalise workspaces, secure access, stabilise refresh, and manage capacity. ### Architecture - **Reusable semantic models precede report proliferation:** Centralise entities, relationships, measures, calendars, security, metadata, and performance logic for governed reuse. - **Connectivity mode follows workload evidence:** Select import, DirectQuery, composite, Direct Lake, aggregations, or hybrid approaches from freshness, scale, security, latency, capacity, and source behaviour. - **Workspace and deployment boundaries are explicit:** Separate teams, domains, environments, applications, access, support, capacity, promotion, and lifecycle according to ownership. ### Quality and governance - **One governed metric definition:** Business entities, dimensions, measures, time logic, filters, currency, ownership, and semantic contracts are defined once and tested. - **Versioned analytical delivery:** Models, reports, dashboards, permissions, data sources, environments, tests, deployment, and rollback follow controlled lifecycle practices. - **Usable and trustworthy analysis:** Freshness, performance, accessibility, row-level security, lineage, documentation, adoption, and decision workflows are measured. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Power BI tenant, workspace, capacity, model, report, gateway, security, usage, cost, and risk assessment - Semantic, report, data, gateway, workspace, deployment, governance, and operating architecture - Production semantic models, DAX, reports, dashboards, apps, dataflows, gateways, and integrations - Row and object security, Entra groups, sensitivity, sharing, audit, and access controls - Refresh, testing, deployment, performance, monitoring, capacity, incident, and cost controls - Analyst, BI developer, administrator, governance, operator, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad consolidate duplicate Power BI semantic models?** Yes. We inventory sources, entities, measures, relationships, security, reports, refresh, performance, users, dependencies, and ownership before controlled consolidation. - **Should Power BI use Import, DirectQuery, or Direct Lake?** The choice depends on source, freshness, scale, query patterns, security, capacity, performance, model features, operational complexity, and cost. Mixed models may be suitable. - **Can Rokad improve slow Power BI reports?** Yes. We analyse source queries, model design, relationships, DAX, cardinality, visuals, interactions, connectivity, refresh, capacity, gateway, and user behaviour. - **Can Rokad manage Power BI after launch?** Yes. Managed scope can cover refresh, gateways, models, reports, access, workspaces, capacities, performance, incidents, deployment, governance, usage, and new analytics. --- ## [Platform service] Tableau development and platform services Canonical URL: https://rokad.co/en/services/data-engineering/business-intelligence/tableau Platform: Tableau > Rokad designs, develops, migrates, governs, and operates Tableau Cloud and Tableau Server across data sources, dashboards, permissions, deployment, embedding, and analytical workflows. Tableau creates value when published data sources, calculations, permissions, extracts, dashboards, subscriptions, alerts, projects, deployment, lineage, performance, and ownership operate as one analytical platform. Rokad builds and governs this lifecycle for self-service, operational, and executive analytics. ### Designed for - **Teams building interactive visual analytics:** Create governed data sources, calculations, workbooks, dashboards, stories, subscriptions, alerts, and user workflows. - **Enterprises managing Tableau Cloud or Server estates:** Standardise sites, projects, permissions, data sources, refresh, Bridge, extracts, content lifecycle, monitoring, and support. - **Organisations migrating or embedding Tableau:** Move content and users between environments or integrate analytics into customer, partner, and employee applications. ### Implementation risks - **Workbook-level calculations duplicate business logic:** Measures, dimensions, parameters, sets, groups, filters, dates, currency, and status rules diverge across dashboards. - **Permissions and project structure are difficult to reason about:** Sites, projects, nested projects, groups, ownership, capabilities, row security, guest or external access, and exceptions drift. - **Extract and dashboard performance is reactive:** Source queries, joins, calculations, filters, marks, extracts, refresh, concurrency, capacity, network, and user behaviour are not profiled together. ### Platform capabilities - Tableau Cloud and Server assessment, site, project, workbook, data source, role, permission, usage, migration, and governance design - Published data sources, relationships, joins, calculations, parameters, sets, groups, hierarchies, metadata, row security, and semantic reuse - Workbooks, dashboards, stories, actions, navigation, device layouts, accessibility, subscriptions, alerts, and analytical user experience - Live connections, extracts, incremental refresh, Tableau Prep, Bridge, schedules, credentials, failures, and source integration - Sites, projects, groups, licences, ownership, permissions, content certification, lineage, cataloguing, audit, and lifecycle governance - Embedding, connected applications, REST and metadata APIs, extensions, automation, portals, and product integration - Server architecture or Cloud operations, deployment, monitoring, performance, capacity, backup, upgrades, support, and managed analytics ### Implementation system - **Tableau semantic and data layer:** Published sources, relationships, calculations, parameters, metadata, extracts, row security, certification, ownership, and lineage. - **Visual analytical experience:** Workbooks, dashboards, actions, filters, navigation, accessibility, mobile, subscriptions, alerts, and decision workflows. - **Content and access governance:** Sites, projects, groups, roles, permissions, ownership, certification, promotion, review, archive, and deletion. - **Tableau operations:** Refresh, Bridge, extracts, queries, background jobs, capacity, server health, upgrades, incidents, cost, adoption, and support. ### Use cases - **Tableau dashboard programme:** Deliver governed executive, operational, financial, customer, product, workforce, and service analytics from shared data sources. - **Tableau Server or Cloud platform governance:** Define sites, projects, groups, permissions, licences, content lifecycle, certification, refresh, monitoring, and support. - **Tableau migration:** Move workbooks, data sources, extracts, schedules, users, groups, permissions, subscriptions, alerts, and integrations with validation. - **Embedded Tableau analytics:** Integrate dashboards and authorisation into applications with identity, filters, row security, performance, APIs, monitoring, and support. ### Architecture - **Published data sources carry reusable analytical contracts:** Centralise relationships, calculations, metadata, row security, refresh, certification, ownership, and performance where reuse is valuable. - **Project permissions inherit by design:** Structure sites, projects, groups, ownership, exceptions, content roles, external access, and audits to reduce workbook-level permission drift. - **Live and extract modes follow evidence:** Select from freshness, source load, query complexity, concurrency, network, row security, capacity, refresh window, and recovery requirements. ### Quality and governance - **One governed metric definition:** Business entities, dimensions, measures, time logic, filters, currency, ownership, and semantic contracts are defined once and tested. - **Versioned analytical delivery:** Models, reports, dashboards, permissions, data sources, environments, tests, deployment, and rollback follow controlled lifecycle practices. - **Usable and trustworthy analysis:** Freshness, performance, accessibility, row-level security, lineage, documentation, adoption, and decision workflows are measured. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Tableau site or server, project, data source, workbook, permission, refresh, usage, and risk assessment - Data-source, workbook, project, access, refresh, deployment, embedding, and operating architecture - Production published sources, Prep flows, workbooks, dashboards, stories, subscriptions, and alerts - Groups, permissions, row security, certification, lineage, ownership, and content-governance controls - Refresh, Bridge, deployment, testing, performance, monitoring, capacity, upgrade, and incident controls - Analyst, developer, administrator, governance, operator, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad migrate Tableau Server to Tableau Cloud?** Yes. We assess authentication, users, groups, projects, permissions, workbooks, data sources, extracts, Bridge, schedules, subscriptions, extensions, APIs, and network access before migration. - **Can Rokad improve slow Tableau dashboards?** Yes. We profile source queries, relationships, calculations, filters, marks, actions, extracts, refresh, concurrency, server or site capacity, and user behaviour. - **Can Tableau be embedded into our application?** Yes. We design identity, authorisation, trusted or connected access, filters, row security, APIs, responsive layout, performance, telemetry, and support. - **Can Rokad manage Tableau after launch?** Yes. Managed scope can cover refresh, Bridge, data sources, workbooks, permissions, users, performance, Server upgrades, incidents, governance, usage, and new analytics. --- ## [Platform service] Looker development and modelling services Canonical URL: https://rokad.co/en/services/data-engineering/business-intelligence/looker Platform: Looker > Rokad designs, builds, migrates, governs, and operates Looker across LookML semantic models, Explores, dashboards, embedding, Git delivery, security, and Google Cloud integration. Looker places a governed LookML semantic layer between the warehouse and analytical experiences. Rokad designs models, views, Explores, joins, dimensions, measures, derived tables, aggregate awareness, access filters, dashboards, embedding, Git workflows, environments, deployment, performance, and ownership as software-backed analytics products. ### Designed for - **Data teams building a governed semantic layer:** Define reusable business entities, joins, measures, dimensions, time logic, security, documentation, exploration, and metrics in LookML. - **Organisations scaling self-service analytics:** Provide curated Explores, fields, dashboards, folders, permissions, schedules, alerts, and user guidance without duplicating SQL logic. - **Product teams embedding governed analytics:** Integrate Looker content, queries, identity, permissions, row security, APIs, themes, monitoring, and lifecycle into applications. ### Implementation risks - **LookML models expose warehouse structure without business usability:** Views, joins, fields, labels, descriptions, drill paths, defaults, time logic, and curated Explores do not match user questions. - **Persistent derived tables create hidden pipeline responsibilities:** Triggers, dependencies, rebuilds, indexes, failures, freshness, warehouse cost, and recovery are not operated explicitly. - **Git workflow exists but analytical releases remain uncontrolled:** Branches, validation, content dependencies, model changes, permissions, schedules, dashboards, and deployment lack evidence and ownership. ### Platform capabilities - Looker instance, project, model, view, Explore, content, group, role, usage, migration, performance, and governance assessment - LookML projects, models, views, joins, dimensions, dimension groups, measures, parameters, sets, drill fields, and documentation - Explores, extensions, refinements, access filters, user attributes, row security, field controls, aggregate awareness, and reusable semantics - SQL and native derived tables, persistent derived tables, datagroups, triggers, dependencies, indexing, freshness, and cost controls - Dashboards, Looks, folders, boards, schedules, alerts, actions, data delivery, user experience, and adoption workflows - Embedded analytics, signed or cookieless patterns where appropriate, APIs, SDKs, identity, themes, extensions, and application integration - Git, development and production modes, validation, CI, content validation, deployment, permissions, monitoring, support, and managed operation ### Implementation system - **LookML semantic layer:** Projects, models, views, joins, Explores, dimensions, measures, calculations, parameters, security, documentation, and ownership. - **Analytical experiences:** Explores, dashboards, Looks, drills, folders, schedules, alerts, deliveries, embedding, themes, extensions, and user guidance. - **Development and release system:** Git, branches, validation, testing, content dependencies, environments, deployment, model versions, review, and rollback. - **Looker operations:** Queries, PDTs, schedules, failures, permissions, usage, performance, warehouse cost, incidents, support, and lifecycle. ### Use cases - **Looker semantic-model implementation:** Build governed LookML models and Explores for shared business entities, measures, dimensions, security, documentation, and self-service. - **Looker project modernisation:** Refactor duplicated views and measures, improve joins and Explores, stabilise PDTs, add validation, govern releases, and optimise queries. - **Embedded Looker analytics:** Integrate authenticated analytics into customer, partner, or employee products with row security, APIs, themes, and telemetry. - **Looker migration:** Move warehouse connections, LookML, content, users, groups, roles, schedules, permissions, embedding, and operational workflows safely. ### Architecture - **Explores are curated analytical products:** Design grain, joins, fields, defaults, labels, descriptions, drills, performance, security, and ownership around user decisions. - **LookML releases follow software-delivery discipline:** Review branches, validate models and content, test representative queries and security, document changes, deploy, and monitor impact. - **PDTs are operated as data pipelines:** Define triggers, freshness, dependencies, indexes, rebuild, failure, backfill, warehouse usage, monitoring, and consumer impact. ### Quality and governance - **One governed metric definition:** Business entities, dimensions, measures, time logic, filters, currency, ownership, and semantic contracts are defined once and tested. - **Versioned analytical delivery:** Models, reports, dashboards, permissions, data sources, environments, tests, deployment, and rollback follow controlled lifecycle practices. - **Usable and trustworthy analysis:** Freshness, performance, accessibility, row-level security, lineage, documentation, adoption, and decision workflows are measured. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Looker project, LookML, Explore, content, role, permission, PDT, performance, usage, and risk assessment - Semantic, Explore, security, content, embedding, Git, deployment, and operating architecture - Production LookML projects, models, views, Explores, dimensions, measures, PDTs, and documentation - Dashboards, Looks, schedules, alerts, folders, embedding, APIs, and application integrations - Validation, CI, deployment, permissions, monitoring, performance, warehouse-cost, and incident controls - Analyst, LookML developer, administrator, governance, operator, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad build or refactor LookML models?** Yes. We design projects, views, joins, Explores, dimensions, measures, security, PDTs, aggregate awareness, documentation, tests, validation, and deployment workflows. - **Can Rokad improve slow Looker queries?** Yes. We analyse Explore joins, field selection, SQL, warehouse design, PDTs, aggregates, caching, filters, concurrency, schedules, and user patterns. - **Can Looker be embedded into a SaaS product?** Yes. We design tenant identity, authorisation, row security, content, themes, APIs, SDKs, query performance, telemetry, usage, and support. - **Can Rokad operate Looker after launch?** Yes. Managed services can cover LookML, validation, PDTs, queries, dashboards, schedules, permissions, users, embedding, performance, incidents, and new analytical products. --- ## [Platform service] Metabase development and platform services Canonical URL: https://rokad.co/en/services/data-engineering/business-intelligence/metabase Platform: Metabase > Rokad implements, customises, embeds, governs, and operates Metabase Cloud and self-hosted analytics across models, metrics, dashboards, permissions, and applications. Metabase provides accessible self-service analytics through questions, models, metrics, dashboards, subscriptions, alerts, embedding, and administration. Rokad designs the data model, metadata, permissions, collections, row and column controls, deployment, SSO, embedding, caching, performance, upgrades, backup, monitoring, and content lifecycle needed for dependable use. ### Designed for - **Growing companies needing accessible self-service analytics:** Give authorised teams governed models, metrics, questions, dashboards, filters, subscriptions, alerts, and documentation. - **Product teams embedding analytics into applications:** Integrate signed or interactive analytics with tenant identity, data permissions, themes, APIs, performance, and support. - **Organisations requiring self-hosted business intelligence:** Operate application, database, cache, network, identity, secrets, backup, monitoring, upgrades, security, and capacity under control. ### Implementation risks - **Questions and dashboards duplicate analytical logic:** Filters, SQL, joins, categories, dates, metrics, segments, and business rules drift without shared models and metadata. - **Collection permissions do not equal data permissions:** Users can discover content while row, column, table, database, sandbox, group, and embedding boundaries remain inconsistent. - **Self-hosted Metabase lacks application operations:** Application database, upgrades, plugins or drivers, backups, email, cache, secrets, monitoring, scaling, and recovery are not owned. ### Platform capabilities - Metabase Cloud and self-hosted assessment, database, model, metric, question, dashboard, group, permission, usage, migration, and governance design - Database connections, metadata, field types, relationships, categories, formatting, models, metrics, segments, and semantic reuse - Query builder, native SQL, questions, dashboards, filters, drill-through, subscriptions, alerts, caching, and analytical workflows - Collections, groups, data permissions, row and column controls, sandboxes where available, SSO, audit, external users, and governance - Static and interactive embedding, signed access, tenant context, identity, themes, SDK or API integration, and application analytics - Self-hosted application, database, cache, reverse proxy, containers, cloud, secrets, email, backup, monitoring, scaling, and upgrades - Content migration, serialization or deployment workflows where suitable, performance, adoption, support, and managed operation ### Implementation system - **Metabase semantic experience:** Metadata, models, metrics, segments, relationships, categories, formatting, documentation, ownership, and reuse. - **Analytics content:** Questions, SQL, dashboards, filters, drills, subscriptions, alerts, collections, lifecycle, certification, and user guidance. - **Identity and embedding:** Groups, SSO, permissions, row and column controls, tenant context, signed access, themes, APIs, applications, and audit. - **Metabase operations:** Application database, cache, jobs, queries, drivers, email, backups, upgrades, monitoring, capacity, incidents, cost, and support. ### Use cases - **Internal self-service analytics:** Create governed models, metrics, questions, dashboards, collections, permissions, subscriptions, alerts, and user enablement. - **Embedded customer analytics:** Deliver tenant-aware dashboards and exploration inside a product with identity, data security, themes, performance, APIs, and support. - **Self-hosted Metabase platform:** Deploy containers, application database, cache, identity, proxy, secrets, email, backup, monitoring, security, upgrades, and recovery. - **Metabase content modernisation:** Rationalise duplicated questions and dashboards, introduce models and metrics, improve metadata, permissions, performance, and ownership. ### Architecture - **Models and metrics carry reusable business meaning:** Centralise common joins, filters, entities, dimensions, measures, dates, definitions, metadata, documentation, and ownership before dashboard growth. - **Embedding identity reaches the data boundary:** Map product tenants and users through signed or interactive access, groups, row controls, database permissions, filters, audit, and validation. - **The Metabase application database is protected separately:** Back up configuration, users, permissions, content, settings, schedules, and metadata while treating analytical source databases independently. ### Quality and governance - **One governed metric definition:** Business entities, dimensions, measures, time logic, filters, currency, ownership, and semantic contracts are defined once and tested. - **Versioned analytical delivery:** Models, reports, dashboards, permissions, data sources, environments, tests, deployment, and rollback follow controlled lifecycle practices. - **Usable and trustworthy analysis:** Freshness, performance, accessibility, row-level security, lineage, documentation, adoption, and decision workflows are measured. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - Metabase deployment, database, model, metric, content, permission, embedding, usage, and risk assessment - Semantic, content, identity, permission, embedding, infrastructure, deployment, and operating architecture - Production models, metrics, questions, SQL, dashboards, filters, collections, subscriptions, and alerts - SSO, groups, permissions, row and column controls, embedding, themes, APIs, and application integration - Hosting, backup, restore, monitoring, security, performance, upgrade, capacity, and incident controls - Analyst, developer, administrator, product, governance, operator, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad self-host Metabase?** Yes. We design containers or cloud hosting, application database, cache, proxy, SSO, secrets, email, backups, monitoring, security, scaling, upgrades, and recovery. - **Can Metabase be embedded in our product?** Yes. We design tenant and user identity, signed or interactive embedding, data permissions, row controls, themes, APIs, performance, monitoring, and support. - **Can Rokad organise an existing Metabase instance?** Yes. We inventory databases, metadata, questions, SQL, models, metrics, dashboards, collections, permissions, users, schedules, usage, performance, and duplication. - **Can Rokad manage Metabase continuously?** Yes. Managed services can cover hosting, backups, upgrades, drivers, content, permissions, users, embedding, performance, incidents, monitoring, and new analytics. --- ## [Service specialisation] Analytics engineering Canonical URL: https://rokad.co/en/services/data-engineering/analytics-engineering > Rokad applies software-engineering discipline to analytical data through versioned transformations, testing, documentation, lineage, deployment, and semantic modelling. Analytics engineering turns raw warehouse data into reliable, reusable business models. Rokad structures transformation projects, source models, staging, intermediate logic, marts, tests, documentation, lineage, metric definitions, CI/CD, and production operations for analytical data. ### Designed for - **Data teams formalising transformation work:** Move SQL, notebooks, and report logic into versioned, reviewed, tested, documented, and deployable projects. - **Organisations standardising metrics:** Create reusable models and semantic definitions used consistently across dashboards, analysis, applications, and AI. - **Companies scaling analyst self-service:** Provide trusted data products that reduce repeated joins, cleaning, and metric reconstruction by every consumer. ### Challenges - **Business logic is hidden inside dashboards:** Important joins, filters, calculations, and exclusions are duplicated and difficult to test or reuse. - **Transformation changes reach production without evidence:** SQL is not reviewed, tested, documented, compared, or deployed through controlled environments and releases. - **Model dependencies are difficult to understand:** Teams cannot see source lineage, downstream impact, owners, freshness, usage, or the reason a model exists. ### Capabilities - Transformation-project architecture, conventions, layers, and ownership - Source, staging, intermediate, mart, domain, and semantic modelling - SQL, code, macros, reusable packages, incremental models, and snapshots - Schema, uniqueness, relationship, accepted-value, business, and reconciliation tests - Documentation, lineage, exposures, ownership, contracts, and data catalogue integration - Pull requests, CI, environments, deployment, state comparison, and rollback - Metric definitions, semantic layers, observability, performance, and managed operation ### Solution components - **Transformation architecture:** Project layout, layers, naming, grain, materialisation, dependencies, reuse, ownership, and lifecycle. - **Quality system:** Contracts, tests, source freshness, reconciliation, anomaly detection, review, and failure response. - **Delivery system:** Version control, pull requests, CI, environments, state comparison, deployment, documentation, and release evidence. - **Semantic products:** Certified marts, metrics, dimensions, entities, documentation, permissions, and interfaces for BI and analysis. ### Use cases - **dbt or transformation-framework implementation:** Establish repositories, conventions, layers, tests, CI/CD, documentation, environments, and team workflows. - **Metric standardisation:** Move duplicated calculations into governed semantic models with clear grain, dimensions, ownership, and tests. - **Dashboard-logic migration:** Extract joins, cleaning, calculations, and business rules from BI tools into reusable warehouse models. - **Analytics model modernisation:** Restructure slow, opaque, tightly coupled transformations into layered, documented, tested, and incremental data products. ### Architecture and integration - **One grain per model:** Define what each row represents, keys, time, dimensions, measures, history, and ownership before implementation. - **Thin semantic interfaces:** Expose stable business entities and metrics while keeping source complexity and transformation detail behind documented models. - **Change impact before merge:** Use lineage, contracts, tests, state comparison, sampling, and downstream ownership to evaluate transformation changes. ### Quality and control - **Trust through contracts:** Ownership, schemas, semantics, freshness, completeness, access, and failure expectations are explicit between producers and consumers. - **Tested transformation:** Pipelines and models include validation, reconciliation, lineage, observability, and controlled change before decision use. - **Governed access:** Identity, classification, least privilege, retention, masking, audit, and usage boundaries follow the sensitivity of the data. ### Delivery process - **Discover:** Clarify the objective, users, systems, constraints, dependencies, risks, and measurable acceptance criteria. - **Architect:** Define the target design, interfaces, controls, migration or delivery sequence, and operating model. - **Deliver and validate:** Implement in controlled increments with testing, review, documentation, observability, and stakeholder validation. - **Operate and improve:** Establish ownership, service controls, measurement, support, and a prioritised improvement backlog. ### Deliverables - Analytics transformation, metric, quality, and workflow assessment - Project architecture, modelling conventions, ownership, and roadmap - Production source, staging, intermediate, mart, and semantic models - Tests, contracts, reconciliation, documentation, and lineage - CI/CD, environments, deployment, review, and release workflows - Metric catalogue, runbooks, contribution, and operating documentation ### Engagement models - **Assessment and roadmap:** A bounded evidence review, target direction, prioritised risks, and executable next-stage plan. - **Fixed-scope delivery:** A defined implementation, migration, prototype, procurement, or transformation outcome with acceptance criteria. - **Embedded specialists:** Specialists working alongside internal product, engineering, data, operations, security, or procurement teams. - **Managed lifecycle:** Ongoing ownership, maintenance, monitoring, supplier coordination, reliability, security, and improvement. ### Frequently asked questions - **Is analytics engineering only about dbt?** No. dbt is one useful tool. The discipline includes modelling, tests, contracts, version control, review, documentation, lineage, deployment, semantics, and ownership regardless of platform. - **Can Rokad improve an existing dbt project?** Yes. We can review layers, naming, grain, tests, materialisations, incremental logic, performance, packages, CI/CD, documentation, ownership, and metric consistency. - **How much logic should remain in BI tools?** Presentation-specific calculations may remain there, but reusable cleaning, joins, business rules, entities, dimensions, and governed metrics should usually live in tested data models. - **Can analytics models support AI and applications?** Yes. Stable, tested models can serve features, retrieval, APIs, exports, applications, and evaluation, though operational latency and contracts may require additional serving layers. --- ## [Platform service] dbt analytics engineering services Canonical URL: https://rokad.co/en/services/data-engineering/analytics-engineering/dbt Platform: dbt > Rokad designs, builds, migrates, governs, and operates dbt projects across analytical modelling, testing, documentation, lineage, semantic metrics, CI/CD, and data-platform integration. dbt brings software-engineering practices to warehouse and lakehouse transformation. Rokad structures project architecture, sources, staging, intermediate and mart models, materialisations, incremental logic, tests, documentation, exposures, semantic definitions, packages, environments, CI/CD, orchestration, observability, cost, and ownership around trusted analytical products. ### Designed for - **Data teams replacing scripts and opaque warehouse SQL:** Move transformations into versioned models with dependencies, tests, documentation, review, deployment, lineage, and ownership. - **Organisations standardising analytical definitions:** Create governed business entities, dimensions, facts, metrics, semantic models, naming, contracts, and documentation. - **Teams scaling an existing dbt project:** Improve project boundaries, performance, incremental models, packages, CI, environments, orchestration, data quality, and developer experience. ### Implementation risks - **The dbt project mirrors source systems rather than business meaning:** Models expose operational tables without durable entities, dimensions, facts, metrics, ownership, or consumer contracts. - **Incremental models cannot be rebuilt confidently:** Unique keys, late data, schema changes, lookback windows, deletes, backfills, snapshots, and full-refresh behaviour are not designed. - **CI validates SQL syntax but not analytical impact:** Modified models, downstream dependencies, contracts, tests, row changes, performance, documentation, and BI compatibility lack targeted evidence. ### Platform capabilities - dbt Core and managed dbt platform assessment, project architecture, migration, environment, usage, and operating design - Sources, staging, intermediate, fact, dimension, mart, domain, data-vault, wide-table, and semantic modelling - Views, tables, incremental models, snapshots, seeds, ephemeral models, macros, packages, tests, hooks, and materialisation strategy - Source freshness, generic and singular tests, contracts, constraints, unit tests, data quality, reconciliation, and incident integration - Documentation, descriptions, lineage, exposures, ownership, tags, groups, versions, deprecation, and catalogue workflows - Semantic models, metrics, dimensions, entities, time logic, BI integration, governed definitions, and metric lifecycle - Git, code review, CI, slim or state-aware builds, deferral, environments, orchestration, artefacts, observability, performance, cost, and managed operation ### Implementation system - **Analytical model architecture:** Sources, staging, intermediate logic, business entities, facts, dimensions, marts, domains, semantic models, metrics, and ownership. - **dbt engineering system:** Repositories, packages, macros, materialisations, tests, contracts, documentation, state, artefacts, environments, and developer workflows. - **Delivery and orchestration:** Pull requests, CI, selective builds, schedules, dependencies, freshness, retries, backfills, deployment, promotion, and rollback or roll-forward. - **Analytics operations:** Model runs, failures, quality, freshness, lineage, performance, warehouse cost, incidents, ownership, support, and roadmap. ### Use cases - **dbt project implementation:** Build sources, transformations, marts, semantic definitions, tests, documentation, CI/CD, orchestration, and operating controls. - **Legacy SQL and ETL modernisation:** Move stored procedures, scripts, views, jobs, and duplicated BI logic into versioned, tested, documented analytical models. - **Enterprise metric and semantic programme:** Define shared entities, dimensions, measures, time logic, ownership, validation, BI interfaces, and controlled evolution. - **dbt performance and cost optimisation:** Improve model graph, materialisations, incremental logic, predicates, clustering or partition use, schedules, concurrency, and warehouse selection. ### Architecture - **Layering communicates responsibility, not ceremony:** Use staging, intermediate, mart, domain, semantic, and other layers only where they clarify contracts, reuse, testing, ownership, and change. - **Incremental logic is paired with rebuild and reconciliation paths:** Define keys, change detection, late records, deletes, lookback, schema evolution, full refresh, partitions, and historical validation. - **CI selects by changed analytical impact:** Use state, lineage, contracts, tests, representative data, downstream models, exposures, and performance evidence to validate changes efficiently. ### Quality and governance - **One governed metric definition:** Business entities, dimensions, measures, time logic, filters, currency, ownership, and semantic contracts are defined once and tested. - **Versioned analytical delivery:** Models, reports, dashboards, permissions, data sources, environments, tests, deployment, and rollback follow controlled lifecycle practices. - **Usable and trustworthy analysis:** Freshness, performance, accessibility, row-level security, lineage, documentation, adoption, and decision workflows are measured. ### Delivery process - **Assess:** Clarify the business outcome, current systems, platform constraints, data, integrations, risks, ownership, and measurable acceptance criteria. - **Design:** Define the platform architecture, workflow or storefront model, extensions, integrations, security, environments, and migration sequence. - **Implement and validate:** Build in controlled increments with testing, stakeholder review, observability, documentation, and platform-specific quality controls. - **Launch and operate:** Deploy safely, transfer ownership, monitor production behaviour, support users, and improve the implementation using operational evidence. ### Deliverables - dbt project, source, model, test, documentation, semantic, orchestration, performance, cost, and risk assessment - Project, modelling, semantic, environment, CI/CD, orchestration, quality, and operating architecture - Production dbt sources, models, snapshots, tests, contracts, macros, packages, and documentation - Semantic models, metrics, exposures, ownership, versions, deprecation, and BI integration - CI, selective builds, orchestration, freshness, observability, backfill, performance, and cost controls - Analytics engineer, BI, data, governance, operator, contribution, and handover documentation ### Engagement models - **Assessment and roadmap:** A bounded review of the current platform, requirements, gaps, risks, architecture, and an executable next-stage plan. - **Fixed-scope implementation:** A defined integration, migration, storefront, application, workflow, or platform outcome with explicit acceptance criteria. - **Embedded platform specialists:** Specialists working alongside internal product, engineering, operations, marketing, data, or enterprise teams. - **Managed platform evolution:** Ongoing maintenance, releases, integrations, support, optimisation, governance, and roadmap execution after launch. ### Frequently asked questions - **Can Rokad migrate stored procedures and scripts into dbt?** Yes. We inventory logic, dependencies, temporary state, schedules, transactions, parameters, outputs, consumers, performance, and recovery before translating suitable transformations. - **Can Rokad improve an existing dbt project?** Yes. We review architecture, duplication, macros, packages, materialisations, incremental logic, tests, contracts, documentation, CI, orchestration, performance, warehouse cost, and ownership. - **Can dbt define shared business metrics?** Yes. We can design semantic models and metrics with entities, dimensions, measures, time behaviour, filters, ownership, validation, versioning, documentation, and BI consumption. - **Can Rokad operate dbt after launch?** Yes. Managed services can cover runs, failures, freshness, tests, incidents, models, documentation, CI, packages, platform changes, performance, cost, and new analytical products. --- ## [journals] Hello, world Canonical URL: https://rokad.co/en/journals/hello-world > Why we built a markdown-first multilingual TanStack Start template. # Hello, world Welcome to **Lumen** — a content-driven template for TanStack Start. It ships with five languages, four content collections, and every SEO surface you'd want: a multi-language sitemap, RSS feeds, `llms.txt`, and JSON-LD. ## Why markdown - Easy to author and review in pull requests. - Trivial to translate side-by-side. - Bundled at build time — no database, no cold starts. --- ## [case-studies] Anubase Canonical URL: https://rokad.co/en/case-studies/anubase > A repo-first, multi-cloud application platform designed to make production deployment more portable, observable, secure, and cost-aware. ## The product direction Anubase is a repo-first, full-stack cloud application platform being developed for founders, product teams, agencies, and engineering organisations that need a simpler path from source code to reliable production infrastructure. The platform is designed around a multi-cloud strategy rather than a single-provider runtime. Its goal is to preserve developer experience while improving cost visibility, deployment portability, security controls, and operational ownership. ## The problem Modern deployment platforms make initial delivery easy, but teams can encounter rising infrastructure cost, provider lock-in, limited runtime control, fragmented observability, and security controls that arrive too late in the product lifecycle. Anubase is intended to provide a coherent control plane across those concerns. ## Platform scope - Repository-connected projects and automated deployments. - Multi-tenant teams, projects, roles, and access controls. - Preview environments, production releases, rollback, and deployment history. - Multi-cloud and container-oriented runtime orchestration. - Domains, TLS, logs, metrics, usage, and billing boundaries. - Git webhook processing and deployment automation. - AI-assisted DevOps analysis and release guidance. - Security agents, policy checks, firewall intelligence, and production gates. - Dashboard and CLI workflows for developers and operators. ## Architecture direction Anubase separates the application experience from provider-specific infrastructure. The control plane coordinates projects, builds, deployments, environments, policy, observability, and billing while runtime adapters execute workloads on supported infrastructure. The platform has also been developed through local Kubernetes, microVM, Kata Containers, tunnel, DNS, and orchestration experiments to validate the operational model beneath the product interface. ## Commercial model The initial adoption path includes free hosting for a limited static project, with paid capabilities for additional projects, backend runtimes, team collaboration, production observability, AI security controls, and advanced infrastructure governance. ## Current stage Anubase is in active platform development, with the control-plane, orchestration, dashboard, runtime, security, and local-development foundations being developed as one integrated system. --- ## [case-studies] Arth.sh Canonical URL: https://rokad.co/en/case-studies/arth-sh > An AI-native, repository-to-production control plane for understanding, changing, verifying, deploying, and operating software across stacks and platforms. ## The product direction Arth.sh is being built as an **agnostic repository-to-production hub**: an AI-native control plane for understanding, changing, verifying, deploying, and operating software without forcing teams into one framework, cloud, runtime, or hosting platform. The product begins with the repository rather than a generated sandbox. It is designed to import an existing codebase, understand how the system is structured, and retain project memory across planning, implementation, review, deployment, and operation. ## The problem Current AI development tools are often excellent at producing a screen or a small application, but become less dependable when software already has history, multiple services, deployment constraints, tests, data contracts, infrastructure, and human review requirements. Arth addresses that gap by treating software delivery as a controlled engineering loop rather than a one-shot generation task. ## What Rokad is building - Repository and architecture understanding across supported stacks. - Change planning with dependency and impact analysis. - AI-assisted implementation that remains visible and reviewable. - Verification through tests, checks, previews, and deployment evidence. - Git-native branches, commits, pull requests, and reversible changes. - Deployment adapters for multiple platforms and container targets. - Production feedback through logs, traces, incidents, and project memory. - Human approval at the points where risk or ownership requires it. ## Product principles ### Agnostic by architecture Frameworks, runtimes, clouds, and deployment providers are adapters around the control plane—not assumptions embedded into the product. ### Repository-native The repository remains the source of truth. Arth works with existing engineering practices instead of hiding changes inside an isolated proprietary workspace. ### Production-oriented Planning, testing, deployment, rollback, observability, and operational context are treated as part of software creation from the beginning. ### Human-controlled AI increases engineering throughput, but the user retains control over decisions, changes, approvals, and releases. ## Current stage Arth is in active development. The first production vertical slice covers repository import, system understanding, an AI-assisted engineering loop, verification, Git synchronization, preview deployment, and controlled release foundations. --- ## [case-studies] Bharatsaga Canonical URL: https://rokad.co/en/case-studies/bharatsaga > An India-first, research-led institution for awareness, strategic dialogue, and long-term nation-building across technology, economy, culture, governance, and science. ## The institution Bharatsaga is a mission-driven, India-first think tank and public-interest institution being developed around research, awareness, strategic dialogue, and later-stage funding of high-impact work. Its subject areas include geopolitics, nation-building, artificial intelligence, scientific pursuits, culture, economy, business, governance, youth, and civilizational studies. ## The positioning challenge The institution must speak to young citizens, professionals, scholars, entrepreneurs, policymakers, and researchers without becoming a partisan political page, a motivational brand, or a casual news account. The work therefore centres on building institutional credibility from the beginning: disciplined research, serious editorial standards, a recognizable visual system, clear governance, and a digital platform designed for long-term knowledge production. ## What Rokad is developing - Institutional positioning and narrative architecture. - A monochrome, editorial visual identity rooted in Indian context without decorative excess. - A repeatable publication and social-content system. - Research, article, report, author, topic, and archive structures. - A modern organisational and editorial website. - Authentication, publishing, storage, and administrative workflows. - Future foundations for strategic dialogue, programmes, partnerships, and funding. ## Design system Bharatsaga uses a restrained editorial language built around black, ivory, graphite, strong typography, minimal data graphics, and a consistent institutional signature. The identity is designed to feel culturally rooted and future-oriented while remaining non-partisan and internationally credible. ## Technology direction The platform is being designed around TanStack, Cloudflare Workers, and Supabase for database, authentication, and storage. The architecture supports a public editorial site, structured institutional content, internal publishing workflows, and future programme expansion. ## Current stage Bharatsaga is in active institution, identity, content-system, and platform development. Its early work is focused on establishing a credible foundation before scaling publication volume, partnerships, and public programmes. --- ## [case-studies] Dhal Canonical URL: https://rokad.co/en/case-studies/dhal > An open-source, application-native web application firewall for Node.js APIs with route-aware controls, observability, and a stable v1 contract. ## The product Dhal is an open-source, application-native web application firewall and request-security middleware for Node.js. It runs inside the application request path, where route, identity, body, response, and operational context are available. It is designed to complement edge, CDN, network, authentication, authorization, validation, and infrastructure controls—not replace them. ## The engineering problem External security layers can stop broad classes of malicious traffic, but often lack the context required to distinguish one application route, user, tenant, API key, request body, or business action from another. Dhal brings deterministic controls closer to the application while preserving a monitor-first rollout model and production evidence for every enforcement decision. ## Core capabilities - Express, Fastify, raw `node:http`, and core-engine integrations. - Route-aware policy and operating modes. - IP controls, reputation, rate limiting, and shared Redis or Valkey counters. - SQL injection, XSS, traversal, SSRF, RCE, SSTI, probe, and API-security controls. - Bot, automation, honeypot, and credential-stuffing detection. - Identity-aware enforcement using user, tenant, route, IP, and API-key context. - Structured events, signed telemetry, OpenTelemetry integration, and replay testing. - Diagnostics, readiness checks, compatibility metadata, SBOMs, and release artifacts. ## Controlled adoption Dhal starts safely in monitor mode. Teams can inspect `wouldBlock` decisions, tune route profiles and suppressions, validate latency and false positives, and then enable blocking selectively on higher-risk routes. This approach keeps security rollout observable and reversible instead of forcing an immediate all-or-nothing switch. ## Stable v1 The public v1 release established a frozen compatibility contract, lifecycle controls, distributed stores, diagnostics, signed telemetry, supply-chain artifacts, and production documentation. The roadmap continues with additional framework adapters, OpenAPI inspection, resource budgets, rule bundles, metrics, Redis resilience, and optional cloud-connected capabilities. ## Role within Rokad Dhal is both a maintained public security product and a practical expression of Rokad's application-security, Node.js, observability, DevSecOps, and production-engineering capability. --- ## [case-studies] Dvar Canonical URL: https://rokad.co/en/case-studies/dvar > An open-source policy firewall for AI-agent actions, tool calls, and Model Context Protocol connections. ## The product Dvar is an open-source policy firewall for AI-agent actions, tool calls, and Model Context Protocol connections. It evaluates a proposed action before the side effect occurs and returns a deterministic decision: `allow`, `deny`, or `require_approval`. The product is designed to make agent behaviour inspectable and governable at the boundary where software begins to act on systems, data, infrastructure, or external services. ## The problem AI agents can reason probabilistically while the systems they operate require deterministic control. Prompt instructions alone are not an adequate authorization, approval, or audit boundary for sensitive tool actions. Dvar separates model reasoning from action policy. The agent may propose an operation, but execution proceeds only after the policy runtime evaluates the principal, agent, tenant, environment, capability, tool, and arguments. ## Core capabilities - Declarative YAML and JSON policy. - Deterministic rule precedence and stable reason codes. - `allow`, `deny`, and `require_approval` decisions. - `off`, `monitor`, `enforce`, and `strict` operating modes. - TypeScript and Node.js-first tool wrappers. - JSON Schema argument validation. - Human approval gates for sensitive actions. - Privacy-conscious audit events and replay. - Embedded policy tests and CLI validation. - A path for Model Context Protocol policy enforcement. ## Security boundary Dvar complements application authorization, IAM, secrets management, sandboxing, database permissions, and network policy. It does not replace those controls, and it only protects actions that pass through its interception boundary. This boundary is explicit by design. Dvar is not an agent framework, a generic AI gateway, or a model-based security judge. ## Adoption model Teams can begin in monitor mode, compare expected and actual decisions, run policy tests, review audit evidence, and then introduce enforcement gradually around higher-risk tools and capabilities. ## Current stage Dvar is in pre-stable development. Its current direction focuses on a compact deterministic runtime, clear policy semantics, generic TypeScript integration, approval workflows, auditability, and production-safe rollout. --- ## [case-studies] Kartikey Canonical URL: https://rokad.co/en/case-studies/kartikey > A locally intelligent home and device companion designed for Indian-language interaction, home automation, privacy, and cloud-assisted capability. ## The product direction Kartikey is a connected AI-companion initiative exploring how a useful home assistant can operate with more intelligence on the device while using cloud models only when the task genuinely requires them. The product direction is designed for the Indian market, where language diversity, privacy, connectivity, hardware cost, and support for existing smart-home devices are central product constraints rather than secondary considerations. ## The problem Mainstream voice assistants depend heavily on cloud infrastructure and ecosystem lock-in. A new independent product must offer a clear reason to exist while remaining commercially realistic in a cost-sensitive market. Kartikey approaches this through a hybrid architecture: local command understanding and device control for frequent tasks, combined with cloud-assisted reasoning for complex requests, long-running automation, and richer conversations. ## System direction - On-device handling for common commands and home-control intents. - Indian-language interaction and multilingual routing. - Cloud offload for complex reasoning and heavyweight tasks. - Home-automation orchestration across supported device ecosystems. - Local privacy controls and reduced dependence on continuous connectivity. - Modular hardware architecture for different performance and price tiers. - Companion software for setup, routines, permissions, and device management. - A path toward personalized behaviour without surrendering user control. ## Hardware research The project has evaluated embedded compute and edge-AI options available in India, including local board vendors and Jetson-class hardware. The hardware direction must balance model capability, thermal and power requirements, supply-chain reliability, and a retail price appropriate for the market. ## Product strategy Rather than attempting to replace every existing smart-home ecosystem immediately, Kartikey is being explored as an intelligent local hub that can extend and coordinate compatible devices while differentiating through Indian-language support, local execution, and deeper automation. ## Current stage Kartikey is in research, architecture, and prototype planning. Current work focuses on the local-versus-cloud intelligence boundary, supported hardware, language models, device compatibility, and the economics of a scalable product. --- ## [case-studies] NaitikOS Canonical URL: https://rokad.co/en/case-studies/naitikos > A systems-software initiative exploring a coherent, secure, and locally controlled foundation for future intelligent computing products. ## The initiative NaitikOS is an active Rokad systems-software initiative focused on defining a coherent foundation for locally controlled, secure, and extensible computing products. The project is being approached as a long-term platform direction rather than a surface-level interface exercise. Its purpose is to explore how operating-system architecture, local intelligence, application boundaries, device support, privacy, and developer experience can work as one product system. ## Why it exists Many intelligent products are assembled from disconnected layers: a generic operating environment, cloud-dependent intelligence, application-specific permissions, and device integrations that were never designed to work together. NaitikOS explores a more deliberate foundation in which local capability, system policy, user control, and extensibility are considered from the architecture stage. ## Areas under development - System and application architecture for locally controlled computing. - Clear permission, isolation, and policy boundaries. - Foundations for local AI and cloud-assisted workloads. - Extensible services and application interfaces. - Device, hardware, and peripheral integration strategy. - Update, recovery, diagnostics, and operational reliability. - Developer tooling and packaging direction. - A consistent experience across future Rokad-built intelligent products. ## Engineering approach The initiative is being developed through research, architectural prototypes, and narrowly scoped technical experiments. Decisions are evaluated against security, maintainability, hardware constraints, user ownership, and whether the system can support real products rather than only a conceptual demonstration. ## Current stage NaitikOS remains in research and development. Public details will expand as the architecture, supported product categories, and first implementation boundary become stable enough to document precisely. --- ## [changelog] v1.0 — initial release Canonical URL: https://rokad.co/en/changelog/2026-06-26 > First public release of Lumen. - Multi-language content collections (blog, case-studies, docs, changelog) - Multi-language sitemap with hreflang - RSS, llms.txt, JSON-LD - Sentry integration - Cloudflare Workers deployment --- ## [Documentation / dhal] API and v1 contract Canonical URL: https://rokad.co/en/docs/dhal/api-and-v1-contract > Use the stable Dhal v1 exports, engine contract, package subpaths, and compatibility guarantees. Dhal `1.x` provides a stable package, CLI, and configuration contract. Experimental surfaces are explicitly identified and are not covered by the same compatibility guarantee. ## Core engine ```ts import { createDhal } from "@rokadhq/dhal"; const protection = createDhal({ configPath: "dhal.json" }); ``` `createDhal()` returns a `DhalEngine` with: | Member | Purpose | | --- | --- | | `config` | Fully resolved and validated configuration. | | `events` | Application event bus for decisions and signals. | | `inspect(request)` | Evaluates a normalized request and returns a decision. | | `recordOutcome(request, outcome)` | Records response outcomes used by credential-failure controls. | | `flush(timeoutMs?)` | Drains managed telemetry. | | `close(timeoutMs?)` | Closes the engine and drains managed telemetry. | | `getRuntimeSnapshot()` | Returns counters, lifecycle state, and telemetry health. | ## Decisions ```ts interface DhalDecision { action: "allow" | "block" | "log"; statusCode: number; reason: string; ruleId?: string; score: number; severity?: "info" | "low" | "medium" | "high" | "critical"; wouldBlock?: boolean; meta?: Record; } ``` In monitor mode, a decision that would otherwise block is returned as allowed with `wouldBlock: true`. ## Options ```ts interface DhalOptions { config?: PartialDeep; configPath?: string; logger?: Pick; rateLimitStore?: RateLimitStore; signalStore?: DhalSignalStore; ipReputationProvider?: IpReputationProvider; telemetry?: DhalTelemetry; } ``` ## Stable package subpaths | Import | Surface | | --- | --- | | `@rokadhq/dhal` | Core engine, configuration, stores, telemetry, policy, diagnostics, and stable types. | | `@rokadhq/dhal/express` | Express adapter. | | `@rokadhq/dhal/fastify` | Fastify adapter. | | `@rokadhq/dhal/node-http` | Raw Node HTTP adapter. | | `@rokadhq/dhal/stores/redis` | Redis-compatible rate-limit store. | | `@rokadhq/dhal/stores/redis-signal` | Redis-compatible signal store. | | `@rokadhq/dhal/stores/memory-signal` | In-memory signal store. | | `@rokadhq/dhal/reputation/abuseipdb` | AbuseIPDB provider. | | `@rokadhq/dhal/telemetry/otel` | OpenTelemetry adapter. | | `@rokadhq/dhal/telemetry/webhook` | Webhook telemetry adapter. | | `@rokadhq/dhal/config-schema` | Programmatic JSON Schema access. | | `@rokadhq/dhal/doctor` | Doctor API. | | `@rokadhq/dhal/rules/catalog` | Rule catalog API. | | `@rokadhq/dhal/presets` | Preset API. | | `@rokadhq/dhal/report` | Support-report API. | | `@rokadhq/dhal/compatibility` | Compatibility matrix. | | `@rokadhq/dhal/readiness` | Readiness API. | | `@rokadhq/dhal/migrations` | Configuration migration API. | | `@rokadhq/dhal/stability` | API stability report. | | `@rokadhq/dhal/v1-contract` | Machine-readable v1 contract. | The package also exports `@rokadhq/dhal/dhal.schema.json`. ## Machine-readable contract ```ts import { DHAL_V1_PUBLIC_EXPORTS, DHAL_V1_CLI_COMMANDS, getDhalV1Contract, validateDhalV1Contract } from "@rokadhq/dhal/v1-contract"; ``` Use `validateDhalV1Contract()` in release tooling when you need to verify that the package still satisfies the frozen inventory. ## Compatibility promise Within `1.x`: - stable exports will not be removed or renamed; - stable CLI commands remain available; - schema version `1` remains backward compatible; - deprecated APIs receive migration guidance before removal in a future major version; - experimental APIs can evolve while explicitly marked experimental. AI-assisted autosetup is experimental and should not be treated as part of the stable production contract. ## Supported matrix The v1 release process validates Node.js 20, 22, and 24; Express 4 and 5; Fastify 4 and 5; raw `node:http`; Redis 7; Valkey 8; ESM; CommonJS; TypeScript; packed installation; and release performance budgets. ## Upgrade workflow Before upgrading within v1: ```bash npm install @rokadhq/dhal@latest npx dhal migrate --check npx dhal test-config npx dhal doctor npx dhal readiness --production npx dhal replay fixtures.replay.json ``` Review the changelog, commit configuration changes separately, and retain a tested rollback to the previously pinned version and `monitor` mode. --- ## [Documentation / dhal] CLI and production readiness Canonical URL: https://rokad.co/en/docs/dhal/cli-and-production-readiness > Onboard projects, repair configuration, generate OpenAPI policy, and validate production readiness with the Dhal v1.1 CLI. The `dhal` CLI is included with `@rokadhq/dhal` and can be run through `npx dhal`. ## Core commands ```bash npx dhal add npx dhal init npx dhal test-config npx dhal migrate --check npx dhal doctor npx dhal doctor --fix --dry-run npx dhal openapi inspect openapi.json npx dhal openapi generate openapi.yaml npx dhal readiness --production npx dhal compat npx dhal stability npx dhal rules npx dhal presets list npx dhal replay fixtures.replay.json npx dhal simulate fixtures.simulation.json npx dhal report --output dhal.report.json npx dhal release-check --target stable --require-build ``` ## Guided project onboarding ```bash npx dhal add ``` `dhal add` detects: - Express, Fastify, NestJS, Koa, or Hono from `package.json`; - npm, pnpm, Yarn, or Bun from the project lockfile; - whether `@rokadhq/dhal` is already installed. The default invocation is read-only. It previews a framework preset, a monitor-mode `dhal.json`, a separate integration module, the correct install command, and registration instructions. Write the proposed files after review: ```bash npx dhal add --write ``` Useful options: ```text --framework Override detection with express, fastify, nestjs, koa, hono, or node-http --config Configuration output path --integration Generated integration-module path --write Create proposed files --force Overwrite existing generated output ``` The command never patches existing application source automatically. ## Initialize, validate, and migrate ```bash npx dhal init npx dhal test-config npx dhal migrate --check ``` `init` creates a generic monitor-first configuration. `test-config` parses and validates the effective configuration. `migrate --check` reports whether migration is required without changing files. Use `migrate --write` only after reviewing the proposed migration and committing the current file. ## Doctor and conservative repair ```bash npx dhal doctor npx dhal doctor --fix --dry-run npx dhal doctor --fix ``` Doctor identifies configuration and environment findings that can weaken production behaviour. `doctor --fix` deliberately has a narrow scope. It may: - create a missing monitor-mode starter configuration; - migrate a supported pre-schemaVersion configuration; - create `dhal.json.bak` before changing an existing file. It does not enable blocking, trust proxy headers, Redis, reputation providers, OpenTelemetry, or webhooks automatically. Use `--dry-run` to preview repairs and `--no-backup` only when another backup mechanism is already in place. ## Framework presets ```bash npx dhal presets list npx dhal presets show nestjs-api npx dhal presets apply hono-node-api --output dhal.hono.json ``` Version 1.1 adds monitor-first framework presets: ```text express-api fastify-api nestjs-api koa-api hono-node-api node-http-api ``` The existing operational presets remain available, including `starter`, `api-production`, `auth-hardened`, `strict-json-api`, `behind-proxy`, and `observability`. Presets are explicit configuration overlays. Review and validate generated output before deployment. ## OpenAPI inspection Inspect an OpenAPI description without generating configuration: ```bash npx dhal openapi inspect openapi.json npx dhal openapi inspect openapi.yaml ``` JSON documents are parsed structurally. YAML uses a conservative scanner for common OpenAPI path, method, tag, security, and request-content declarations. Complex YAML using anchors, merge keys, or external references should be converted to JSON first. Inspection classifies signals such as: - authentication operations; - uploads and multipart requests; - webhooks and callbacks; - expensive search, export, batch, report, or inference operations; - explicitly public operations; - JSON request bodies. ## Generate monitor-mode policy from OpenAPI Preview generated policy: ```bash npx dhal openapi generate openapi.yaml ``` OpenAPI parameters are converted to Dhal wildcard paths: ```text /users/{userId} -> /users/* /orgs/{orgId}/users/{userId} -> /orgs/*/users/* ``` Every generated route remains in `monitor` mode. Existing owner-managed route profiles are preserved and reported as `preserve-existing`. Write into `dhal.json` with a backup: ```bash npx dhal openapi generate openapi.yaml --config dhal.json --write ``` Or write a separate proposal: ```bash npx dhal openapi generate openapi.json --output dhal.openapi.json ``` Use `--force` to replace an existing separate output, `--no-backup` to suppress the configuration backup, and `--default-max` to change the default generated rate limit. Generated policy is a security proposal, not an authorization model. Review grouped HTTP methods, route classifications, rate limits, and content-type assumptions before enforcement. ## Readiness, compatibility, and stability ```bash npx dhal readiness --production npx dhal compat npx dhal stability ``` Readiness evaluates whether configuration is suitable for production enforcement. Compatibility reports the tested runtime and integration matrix. Stability reports the contract level of public API surfaces. Treat readiness as one deployment input, not a replacement for replay testing or application-specific review. ## Rules, replay, and simulation ```bash npx dhal rules npx dhal replay fixtures.replay.json npx dhal simulate fixtures.simulation.json ``` Keep replay fixtures for known-good and known-malicious requests in version control. A production promotion should fail when known-good traffic unexpectedly blocks or malicious fixtures stop matching the expected control. ## CI policy The `policy.ci` section can enforce organization requirements: ```json { "policy": { "ci": { "failOnModes": ["off"], "requireWebhookSigning": true, "requireNonMonitorRouteForRules": ["credential_stuffing.threshold_exceeded"], "disallowExpiredSuppressions": true } } } ``` Run it in CI: ```bash npx dhal ci ``` ## Support report and release check ```bash npx dhal report --output dhal.report.json npx dhal release-check --target stable --require-build ``` Review support reports before sharing them. Do not attach secrets, credentials, tokens, or unredacted production traffic to public issues. ## Enforcement checklist Before changing any route to `block` or `strict`, confirm: - the exact Dhal version is pinned; - Node.js and framework versions are supported; - `schemaVersion` is `"1"`; - generated onboarding or OpenAPI changes were reviewed; - `test-config`, migration check, doctor, and readiness pass; - known-good and malicious replay fixtures pass; - Redis or Valkey is shared for multi-instance deployments; - webhook signing and redaction are configured; - graceful shutdown calls `close()`; - rollback to `monitor` mode is documented and tested. --- ## [Documentation / dhal] Configuration Canonical URL: https://rokad.co/en/docs/dhal/configuration > Understand dhal.json, operating modes, runtime safety, and configuration precedence. Dhal uses schema version `1`. The default configuration file is `dhal.json`, although every adapter and `createDhal()` can receive a different `configPath`. ## Configuration precedence Dhal builds its effective configuration in this order: 1. built-in defaults; 2. values loaded from `configPath`; 3. the inline `config` override passed to `createDhal()` or an adapter. Objects are merged recursively. Arrays are replaced rather than concatenated. ```ts import { createDhal } from "@rokadhq/dhal"; const protection = createDhal({ configPath: "dhal.json", config: { mode: "monitor", response: { message: "Request rejected by application security policy" } } }); ``` ## Minimal production-onboarding configuration ```json { "schemaVersion": "1", "mode": "monitor", "trustProxy": false, "runtime": { "onInternalError": "allow", "internalErrorStatusCode": 500, "maxInspectionMs": 25, "bypass": { "enabled": true, "paths": ["/health", "/healthz", "/ready", "/readyz"], "methods": ["OPTIONS"] } }, "rateLimit": { "enabled": true, "store": "memory", "keyBy": ["ip", "route"], "default": { "windowSeconds": 60, "max": 120 }, "routes": {} } } ``` Unspecified values inherit Dhal's defaults. ## Core fields | Field | Purpose | | --- | --- | | `schemaVersion` | Must be `"1"` for the v1 configuration contract. | | `mode` | Global `off`, `monitor`, `block`, or `strict` behaviour. | | `trustProxy` | Allows trusted forwarding headers to determine the client IP. Enable only behind a trusted proxy. | | `runtime` | Internal-error, inspection-budget, and bypass behaviour. | | `identity` | Header names used to resolve user, tenant, and API-key identities. | | `ip` | Allow/block lists and reputation settings. | | `rateLimit` | Default and route-specific request limits. | | `rules` | Signature, bot, payload, API, header, content-type, honeypot, and credential controls. | | `routes` | Route-level overrides for modes, rules, limits, reputation, and responses. | | `policy` | Severity, suppressions, sampling, audit metadata, and CI requirements. | | `observability` | Redaction, logs, events, OpenTelemetry, correlation, and webhooks. | | `response` | Default blocking status code and public message. | ## Runtime safety ```json { "runtime": { "onInternalError": "allow", "internalErrorStatusCode": 500, "maxInspectionMs": 25, "bypass": { "enabled": true, "paths": ["/health", "/ready"], "methods": ["OPTIONS"] } } } ``` Use `onInternalError: "allow"` during initial monitoring and when availability is the primary objective. `strict` mode or `onInternalError: "block"` is appropriate only after dependencies and failure behaviour have been validated. Bypass paths and methods skip inspection. Keep this list narrow and limited to endpoints that cannot process untrusted application input. ## Proxy trust Do not enable `trustProxy` merely because the application is deployed behind a load balancer. First confirm that direct access is blocked and that the proxy overwrites, rather than appends untrusted, forwarding headers. ```json { "trustProxy": true } ``` Incorrect proxy trust can allow an attacker to control the IP address used for allow lists, reputation, rate limits, and audit events. ## Inline configuration Inline configuration is useful for environment-specific values that are not secrets: ```ts const protection = createDhal({ configPath: "dhal.json", config: { mode: process.env.DHAL_MODE === "block" ? "block" : "monitor" } }); ``` Store secrets in environment variables or a secrets manager. Configuration fields such as `apiKeyEnv` and `secretEnv` contain environment-variable names, not secret values. ## Validate the file ```bash npx dhal test-config npx dhal migrate --check ``` The package also exports the JSON Schema as `@rokadhq/dhal/dhal.schema.json` and programmatically through `getDhalConfigJsonSchema()`. --- ## [Documentation / dhal] Getting started Canonical URL: https://rokad.co/en/docs/dhal/getting-started > Install Dhal v1.1 and protect a Node.js application with guided onboarding. Dhal is an app-native web application firewall and request-security layer for Node.js. Version 1.1 supports Express, Fastify, NestJS, Koa, Hono on Node.js, and raw `node:http` servers. Dhal complements CDN, edge, network, authentication, authorization, and input-validation controls. It does not replace volumetric DDoS protection or infrastructure security. ## Requirements - Node.js 20 or newer - A modern npm-compatible package manager - Redis or Valkey for shared counters when multiple application instances protect the same routes ## Install ```bash npm install @rokadhq/dhal ``` The npm package is `@rokadhq/dhal`, the CLI command is `dhal`, and the default configuration file is `dhal.json`. ## Recommended: guided onboarding Run `dhal add` from the application root: ```bash npx dhal add ``` The default command is read-only. It detects the framework and package manager, previews a monitor-mode configuration, generates a reviewable framework integration module, and prints exact registration instructions. After reviewing the plan, create the proposed files: ```bash npx dhal add --write ``` Dhal does not patch existing application source automatically. Existing output files are not overwritten unless `--force` is supplied. Raw `node:http` applications can be selected explicitly: ```bash npx dhal add --framework node-http --write ``` ## Manual configuration You can still create the generic starter configuration directly: ```bash npx dhal init ``` The generated configuration starts in `monitor` mode. Dhal evaluates requests and records what it would block without rejecting traffic. ## Framework entrypoints ### Express ```ts import { dhal } from "@rokadhq/dhal/express"; app.use(express.json({ limit: "1mb" })); app.use(dhal({ configPath: "dhal.json" })); ``` ### Fastify ```ts import { dhalFastify } from "@rokadhq/dhal/fastify"; await app.register(dhalFastify({ configPath: "dhal.json" })); ``` ### NestJS ```ts import { installDhalNest } from "@rokadhq/dhal/nest"; const app = await NestFactory.create(AppModule); await installDhalNest(app, { configPath: "dhal.json" }); await app.listen(3000); ``` Install Dhal after creating the Nest application and before `app.listen()`. The adapter detects whether Nest uses Express or Fastify. ### Koa ```ts import { dhalKoa } from "@rokadhq/dhal/koa"; app.use(dhalKoa({ configPath: "dhal.json" })); ``` Register Dhal before application routes and middleware that should only execute after inspection. ### Hono on Node.js ```ts import { dhalHono } from "@rokadhq/dhal/hono"; app.use("*", dhalHono({ configPath: "dhal.json" })); ``` The Hono adapter consumes standard Web `Request` and `Response` objects and is supported on the Node.js runtime. ### Raw `node:http` ```ts import { createNodeHttpDhal } from "@rokadhq/dhal/node-http"; const protection = createNodeHttpDhal({ configPath: "dhal.json" }); ``` See the framework integrations chapter for complete lifecycle and identity examples. ## Validate and repair before enforcement ```bash npx dhal test-config npx dhal migrate --check npx dhal doctor npx dhal doctor --fix --dry-run npx dhal readiness --production ``` `doctor --fix` applies only conservative mechanical repairs. It can create a missing monitor-mode starter file or migrate a compatible configuration with backup support. It does not enable blocking, proxy trust, Redis, telemetry, or external reputation services automatically. A safe rollout is: 1. Deploy globally in `monitor` mode. 2. Replay known-good traffic and review `wouldBlock` events. 3. Enable `block` only on selected high-risk routes. 4. Validate latency, false positives, and backend availability. 5. Expand enforcement gradually. ## Operating modes | Mode | Behaviour | | --- | --- | | `off` | Disables inspection. | | `monitor` | Allows requests while recording decisions that would have blocked them. | | `block` | Rejects requests that match an enforced control. | | `strict` | Also blocks when internal security evaluation fails. | Route profiles can override the global mode, allowing gradual enforcement without changing the whole application at once. --- ## [Documentation / dhal] Framework integrations Canonical URL: https://rokad.co/en/docs/dhal/integrations > Integrate Dhal v1.1 with Express, Fastify, NestJS, Koa, Hono, node:http, or the core engine. Dhal v1.1 ships dedicated adapters for Express, Fastify, NestJS, Koa, Hono on Node.js, and raw `node:http`. Every adapter reuses the same Dhal engine, configuration model, stores, telemetry, and decision lifecycle. ## Express ```ts import express from "express"; import { dhal } from "@rokadhq/dhal/express"; const app = express(); app.use(express.json({ limit: "1mb" })); app.use(dhal({ configPath: "dhal.json" })); ``` Place body parsers before Dhal when body-aware rules should inspect parsed payloads. The adapter reads `req.body`, an optional `req.rawBody`, identity fields, and the final response status. Use `dhalFromEngine(engine)` when you create the engine yourself for custom stores, telemetry, or lifecycle control. ## Fastify ```ts import Fastify from "fastify"; import { dhalFastify } from "@rokadhq/dhal/fastify"; const app = Fastify(); await app.register(dhalFastify({ configPath: "dhal.json" })); ``` Dhal inspects requests in `preHandler` and records response outcomes in `onResponse`. Use `dhalFastifyFromEngine(engine)` with a pre-created engine. ## NestJS ```ts import { NestFactory } from "@nestjs/core"; import { installDhalNest } from "@rokadhq/dhal/nest"; import { AppModule } from "./app.module.js"; const app = await NestFactory.create(AppModule); const dhal = await installDhalNest(app, { configPath: "dhal.json" }); await app.listen(3000); ``` Install Dhal after creating the Nest application and before `app.listen()`. Dhal detects whether the Nest HTTP application uses Express or Fastify and installs the corresponding stable adapter. For an existing engine: ```ts import { installDhalNestFromEngine } from "@rokadhq/dhal/nest"; const installation = await installDhalNestFromEngine(app, engine); ``` The returned installation exposes `engine`, the detected `platform`, and `close()`. Nest microservice transports without an HTTP adapter are outside this integration. ## Koa ```ts import Koa from "koa"; import { dhalKoa } from "@rokadhq/dhal/koa"; const app = new Koa(); app.use(dhalKoa({ configPath: "dhal.json" })); ``` Register Dhal before application routes. The adapter: - inspects the request before downstream middleware; - terminates the middleware chain for blocked requests; - sets `x-dhal-action` and `x-dhal-rule`; - records the downstream response status; - reads optional identities from `context.state.userId`, `tenantId`, `apiKeyId`, or `context.state.user.id`. Use `dhalKoaFromEngine(engine)` for custom lifecycle management. ## Hono on Node.js ```ts import { Hono } from "hono"; import { dhalHono } from "@rokadhq/dhal/hono"; const app = new Hono(); app.use("*", dhalHono({ configPath: "dhal.json" })); ``` The Hono adapter consumes standard Web `Request` and `Response` objects, returns a controlled response when Dhal blocks, and records the final downstream response status. Identity values can be exposed through `context.var.userId`, `tenantId`, `apiKeyId`, or `context.var.user.id`. The supported v1.1 target is Hono running on Node.js. Edge runtimes are not included in the compatibility commitment. Use `dhalHonoFromEngine(engine)` for an existing engine. ## Raw `node:http` ```ts import http from "node:http"; import { createNodeHttpDhal } from "@rokadhq/dhal/node-http"; const protection = createNodeHttpDhal({ configPath: "dhal.json" }); const server = http.createServer(async (req, res) => { const decision = await protection.inspect(req, res); if (decision.action === "block") return; res.statusCode = 200; res.end("ok"); }); ``` The raw adapter normalizes method, URL, path, headers, client IP, identity headers, and `content-length`. It does not consume the request stream. ## Custom integrations with the core engine ```ts import { createDhal, type DhalRequest } from "@rokadhq/dhal"; const protection = createDhal({ configPath: "dhal.json" }); const request: DhalRequest = { method: "POST", url: "/api/orders?source=web", path: "/api/orders", route: "/api/orders", headers: { "content-type": "application/json" }, ip: "203.0.113.10", body: { productId: "sku_123", quantity: 1 }, userId: "user_123", tenantId: "tenant_456" }; const decision = await protection.inspect(request); ``` After the application response is known, call `recordOutcome()` so response-aware signals can be updated: ```ts await protection.recordOutcome(request, { statusCode: 401 }); ``` ## Lifecycle and blocking responses Create the engine yourself when you need explicit shutdown control: ```ts process.once("SIGTERM", async () => { await protection.close(5_000); process.exit(0); }); ``` Bundled adapters set `x-dhal-action: block` and `x-dhal-rule: `, then return the configured status code and controlled JSON response. Do not expose private decision metadata to untrusted clients. --- ## [Documentation / dhal] Observability and lifecycle Canonical URL: https://rokad.co/en/docs/dhal/observability-and-lifecycle > Configure redaction, events, OpenTelemetry, signed webhooks, runtime health, and graceful shutdown. Dhal emits security decisions while protecting sensitive request information by default. Observability must be treated as part of the security boundary because events can contain route, identity, IP, and rule metadata. ## Redaction ```json { "observability": { "redaction": { "enabled": true, "ip": "mask", "identity": "hash", "userAgent": "full" } } } ``` IP and identity redaction modes are `none`, `mask`, `hash`, and `omit`. User agents can be retained with `full` or removed with `omit`. Keep redaction enabled unless a documented incident-response requirement justifies collecting the original value. ## Correlation IDs Dhal checks configured headers in order: ```json { "observability": { "correlation": { "headers": ["x-request-id", "x-correlation-id", "traceparent"] } } } ``` A custom integration can also set `correlationId` directly on `DhalRequest`. ## Logs and events ```json { "observability": { "logs": { "enabled": true, "format": "json" }, "events": { "enabled": true } } } ``` The engine exposes an event bus through `protection.events`. Application listener failures are isolated from request decisions and counted in the runtime snapshot. ## OpenTelemetry Install the OpenTelemetry API in the host application: ```bash npm install @opentelemetry/api ``` ```json { "observability": { "otel": { "enabled": true, "serviceName": "orders-api", "emitAllowedRequests": false } } } ``` Dhal uses the application's OpenTelemetry provider. Configure exporters and resource metadata in the host application. ## Signed webhooks ```json { "observability": { "webhooks": { "enabled": true, "urls": ["https://security.example.com/dhal/events"], "timeoutMs": 750, "emitAllowedRequests": false, "signing": { "enabled": true, "secretEnv": "DHAL_WEBHOOK_SECRET", "signatureHeader": "x-dhal-signature", "timestampHeader": "x-dhal-timestamp", "idHeader": "x-dhal-event-id" } } } } ``` Webhook receivers should verify the timestamp, event ID, and HMAC signature; reject stale timestamps and replayed IDs; and return a 2xx response only after accepting the event. Delivery is bounded to prevent unbounded memory growth. Non-2xx responses count as failed deliveries, and deliveries can be drained during shutdown. ## Custom telemetry ```ts import type { DhalTelemetry } from "@rokadhq/dhal"; const telemetry: DhalTelemetry = { recordDecision(event) { securityQueue.publish(event); } }; const protection = createDhal({ telemetry }); ``` Synchronous telemetry failures are isolated and counted. A custom adapter should avoid blocking the request path and should implement its own bounded queueing strategy. ## Runtime snapshot ```ts const snapshot = protection.getRuntimeSnapshot(); console.log({ inspected: snapshot.inspected, allowed: snapshot.allowed, blocked: snapshot.blocked, wouldBlock: snapshot.wouldBlock, internalErrors: snapshot.internalErrors, overBudget: snapshot.overBudget, eventListenerErrors: snapshot.eventListenerErrors, telemetryErrors: snapshot.telemetryErrors, pendingTelemetry: snapshot.telemetry?.pending, droppedTelemetry: snapshot.telemetry?.dropped }); ``` Export these values through an internal metrics system. Alert on sustained internal errors, over-budget inspections, listener errors, failed deliveries, or dropped telemetry. ## Graceful shutdown ```ts async function shutdown(signal: string) { console.log(`Received ${signal}; draining Dhal.`); await protection.close(5_000); process.exit(0); } process.once("SIGTERM", () => void shutdown("SIGTERM")); process.once("SIGINT", () => void shutdown("SIGINT")); ``` - `flush(timeoutMs?)` drains managed telemetry without closing the engine. - `close(timeoutMs?)` stops new inspections, drains telemetry, and removes event listeners. - Calling `inspect()` after `close()` throws an error. --- ## [Documentation / dhal] Rate limiting and identity Canonical URL: https://rokad.co/en/docs/dhal/rate-limiting-and-identity > Build Dhal rate-limit keys from IP, route, user, tenant, and API-key identities. Dhal rate limits can be keyed by more than source IP. This is important for authenticated APIs, multi-tenant systems, and applications where many users share a network address. ## Global rate limit ```json { "rateLimit": { "enabled": true, "store": "memory", "keyBy": ["ip", "route"], "default": { "windowSeconds": 60, "max": 120 }, "routes": { "/api/search": { "windowSeconds": 60, "max": 30 } } } } ``` Route-limit patterns support exact paths and `*` wildcards. The most specific matching pattern wins. ## Identity keys Rate limits support these key components: - `ip` - `route` - `userId` - `tenantId` - `apiKeyId` Credential-stuffing controls additionally support `userAgent`. ```json { "rateLimit": { "keyBy": ["tenantId", "userId", "route"] } } ``` Choose keys that match the abuse boundary. For example: | Use case | Suggested key | | --- | --- | | Public unauthenticated endpoint | `ip`, `route` | | Authenticated user action | `userId`, `route` | | Tenant-wide quota | `tenantId`, `route` | | API integration quota | `apiKeyId`, `route` | | Login abuse | `ip`, `route`, optionally `userAgent` | ## Identity headers Dhal resolves identities from request properties first and configured headers second. ```json { "identity": { "headers": { "userId": ["x-dhal-user-id", "x-user-id"], "tenantId": ["x-dhal-tenant-id", "x-tenant-id"], "apiKeyId": ["x-dhal-api-key-id", "x-api-key-id"] } } } ``` Only trust identity headers that are removed and rewritten by your authentication layer or trusted gateway. Never accept client-supplied identity headers unchanged from the public internet. ## Route-level limits ```json { "routes": { "/api/export": { "mode": "block", "rateLimit": { "enabled": true, "windowSeconds": 3600, "max": 10, "keyBy": ["tenantId", "userId"] } } } } ``` A route profile can inherit unspecified values from the global rate-limit configuration. ## Memory store The memory store is appropriate for: - local development; - tests; - a single application process; - monitor-only evaluation where exact distributed counts are not required. It is not a distributed control. Each process maintains independent counters. ## Custom stores A rate-limit store implements: ```ts interface RateLimitStore { consume(key: string, limit: { windowSeconds: number; max: number; }): Promise<{ allowed: boolean; remaining: number; resetAt: number; }>; } ``` Pass the store through `createDhal()` or any framework adapter: ```ts const protection = createDhal({ configPath: "dhal.json", rateLimitStore: myStore }); ``` For horizontally scaled production deployments, use the provided Redis-compatible store or another shared implementation with equivalent atomicity and expiry behaviour. --- ## [Documentation / dhal] Reputation and distributed deployments Canonical URL: https://rokad.co/en/docs/dhal/reputation-and-distributed-deployments > Use Redis or Valkey state and configure IP reputation without silent security downgrades. Multiple application instances must share security state when they protect the same users and routes. Dhal supports Redis or Valkey for distributed rate-limit and credential-failure counters. ## Install the Redis client ```bash npm install ioredis ``` ## Configure shared stores ```ts import Redis from "ioredis"; import { RedisRateLimitStore, RedisSignalStore, createDhal } from "@rokadhq/dhal"; const redis = new Redis(process.env.REDIS_URL!); const protection = createDhal({ configPath: "dhal.json", rateLimitStore: new RedisRateLimitStore(redis, { prefix: "production:dhal:rate-limit" }), signalStore: new RedisSignalStore(redis, { prefix: "production:dhal:signals" }) }); ``` Set the declared store in configuration: ```json { "rateLimit": { "enabled": true, "store": "redis" } } ``` Use separate prefixes for each application and environment. Protect the datastore with authentication, network isolation, TLS where supported, and an eviction policy suitable for short-lived security counters. ## No silent fallback in enforcement Stable v1 refuses to start an enforcing deployment that declares `rateLimit.store: "redis"` without receiving a distributed `rateLimitStore`. Monitor-only operation logs a warning and can use the memory store. This behaviour prevents an intended global limit from silently becoming a weaker per-instance limit. Credential-stuffing signals use `signalStore`. Supply `RedisSignalStore` whenever authentication failures must be counted across instances. ## IP reputation ```json { "ip": { "reputation": { "enabled": true, "provider": "abuseipdb", "apiKeyEnv": "ABUSEIPDB_API_KEY", "minScore": 75, "cacheTtlSeconds": 86400, "maxAgeInDays": 30, "mode": "async", "timeoutMs": 750 } } } ``` Set the API key in the environment, never in `dhal.json`: ```bash export ABUSEIPDB_API_KEY="..." ``` Use `async` mode for general traffic when reputation should enrich subsequent decisions without adding provider latency to every request. Use `blocking` only when the route can tolerate provider latency and dependency failure. An enforcing deployment with blocking reputation refuses to start if no provider is available. ## Route-level reputation ```json { "routes": { "/api/admin/*": { "mode": "block", "ipReputation": { "enabled": true, "minScore": 60, "mode": "blocking" } } } } ``` ## Custom provider ```ts import type { IpReputationProvider } from "@rokadhq/dhal"; const provider: IpReputationProvider = { name: "internal-reputation", async check(ip) { return { ip, provider: "internal-reputation", score: 0, checkedAt: Date.now(), expiresAt: Date.now() + 60_000 }; } }; const protection = createDhal({ configPath: "dhal.json", ipReputationProvider: provider }); ``` Provider scores use a `0` to `100` scale, with larger values representing greater risk. ## Production checklist - Share rate-limit state across all instances serving the same routes. - Share credential-failure state for authentication controls. - Separate key prefixes by application and environment. - Monitor datastore latency and errors. - Test datastore failure behaviour before enforcement. - Use blocking reputation only on routes with an explicit latency and availability decision. - Keep provider and Redis credentials outside the configuration file. --- ## [Documentation / dhal] Rules and route profiles Canonical URL: https://rokad.co/en/docs/dhal/rules-and-route-profiles > Configure Dhal rule packs, route-level enforcement, suppressions, and false-positive controls. Dhal combines deterministic request controls with route-specific policy. Start with broad monitoring, then enforce only where the application behaviour is understood. ## Rule families Dhal v1 includes controls for: - IP allow and block lists; - SQL injection, cross-site scripting, path traversal, SSRF, RCE, SSTI, GraphQL abuse, and common probe signatures; - request-size limits; - header anomalies and conflicting forwarding headers; - content-type consistency; - JSON API positive-security constraints; - bot and automation signals; - honeypot headers, query parameters, and paths; - credential-stuffing failure thresholds; - request rate limits and IP reputation. ## Rule packs Available rule packs are: - `generic-web` - `api` - `auth` - `wordpress` - `strict-api` ```json { "rules": { "packs": ["generic-web", "api"], "sqli": true, "xss": true, "pathTraversal": true, "badUserAgents": true } } ``` Use the CLI to review the rule inventory before enforcement: ```bash npx dhal rules ``` ## Route profiles Route profiles can override the global mode, rules, limits, reputation behaviour, and blocking response. ```json { "schemaVersion": "1", "mode": "monitor", "routes": { "/api/login": { "mode": "block", "tags": ["authentication"], "rateLimit": { "enabled": true, "windowSeconds": 60, "max": 20, "keyBy": ["ip", "route"] }, "rules": { "credentialStuffing": { "enabled": true, "windowSeconds": 300, "maxFailures": 4, "keyBy": ["ip", "route", "userAgent"] } }, "response": { "blockStatusCode": 429, "message": "Too many authentication attempts" } } } } ``` Patterns support exact paths and `*` wildcards: ```json { "routes": { "/api/admin/*": { "mode": "strict" }, "/api/public/*": { "mode": "monitor" } } } ``` When multiple patterns match, Dhal selects the most specific pattern by comparing the non-wildcard length. Set `enabled: false` on a profile to ignore that profile and use the global configuration. ## Bot false-positive controls Bot detection uses multiple signals rather than relying on a single user-agent string. ```json { "rules": { "bot": { "enabled": true, "scoreThreshold": 70, "blockEmptyUserAgent": false, "allowUserAgents": ["trusted-monitor/1.0"], "falsePositiveControls": { "minSignals": 2, "skipStaticAssets": true, "ignorePaths": ["/health", "/ready"], "ignorePrivateIps": false } } } } ``` Prefer raising `minSignals`, adding a narrow allow entry, or applying a route-specific override before disabling bot controls globally. ## JSON API positive security ```json { "rules": { "api": { "enabled": true, "requireJsonContentType": true, "allowedContentTypes": ["application/json", "application/problem+json"], "methodsWithBody": ["POST", "PUT", "PATCH"], "maxJsonDepth": 20, "maxJsonKeys": 500 } } } ``` Apply this globally only to JSON-only services. For mixed applications, enable it on API route profiles. ## Suppressions Suppressions are explicit policy exceptions and remain visible in audit metadata. ```json { "policy": { "suppressions": [ { "id": "approved-validation-scanner", "enabled": true, "ruleId": "honeypot.triggered", "path": "/.well-known/security-canary", "reason": "approved internal validation scanner", "expiresAt": "2027-01-01T00:00:00.000Z" } ] } } ``` Suppressions can match a rule, category, route, path, IP, user, tenant, or API-key identity. Keep them narrow, document the reason, and set an expiry date. ## Severity and sampling Use `policy.severity` to map categories or individual rule IDs to `info`, `low`, `medium`, `high`, or `critical`. Sampling can reduce allowed-event volume while always retaining blocked and would-block events. Do not use sampling as a substitute for alert tuning or storage controls. --- ## [Documentation / dvar] Getting started Canonical URL: https://rokad.co/en/docs/dvar/getting-started > Install Dvar and place deterministic policy controls in front of AI-agent tool actions. Dvar is a policy firewall for AI agents. It evaluates tool actions before side effects occur and returns a deterministic `allow`, `deny`, or `require_approval` decision. Dvar complements application authorization, IAM, sandboxing, secrets management, database permissions, and network policy. It does not replace those controls, and it only protects actions that pass through its interception boundary. ## Status The current release is pre-stable. Review package release notes before upgrading and test policy behaviour before enabling enforcement in production. ## Install ```bash npm install @rokadhq/dvar ``` ## Initialize a policy ```bash npx dvar init npx dvar validate npx dvar test-policy ``` The generated policy starts in `monitor` mode. Monitor mode allows actions to execute while recording the decision Dvar would have enforced. ## Protect a tool ```ts import { createDvar } from "@rokadhq/dvar"; const dvar = await createDvar({ policyPath: "dvar.yaml" }); const readCustomer = dvar.protectTool({ name: "crm.read_customer", capabilities: ["data.read"], inputSchema: { type: "object", additionalProperties: false, required: ["customerId"], properties: { customerId: { type: "string", minLength: 1 }, }, }, execute: async ({ customerId }: { customerId: string }) => ({ customerId, status: "active", }), }); ``` Call the protected tool with execution context: ```ts const customer = await readCustomer( { customerId: "customer-1" }, { principal: { id: "user-1", type: "user" }, agent: { id: "support-agent" }, tenant: { id: "tenant-a" }, environment: "production", }, ); ``` ## Operating modes | Mode | Behaviour | | --- | --- | | `monitor` | Executes the action and records `would_allow`, `would_deny`, or `would_require_approval`. | | `enforce` | Blocks denied and approval-gated actions before the executor runs. | | `strict` | Applies the strongest configured enforcement behaviour. | | `off` | Disables Dvar evaluation for the configured boundary. | ## Current capabilities - Declarative YAML and JSON policies - Deterministic precedence - Generic JavaScript and TypeScript tool wrappers - JSON Schema argument validation - Stable reason codes - Privacy-conscious audit events - Embedded policy tests - JSONL replay that never invokes tools - CLI commands for initialization, validation, diagnostics, testing, replay, and version inspection ## Production rollout 1. Define the tools and capabilities that cross the Dvar boundary. 2. Start in `monitor` mode. 3. Review audit events and policy-test results. 4. Correct unexpected decisions before enforcement. 5. Enable enforcement gradually for high-risk actions. 6. Keep application authorization, IAM, sandboxing, secrets, and infrastructure policy in place. --- ## [Documentation / kingsbell] Architecture and design system Canonical URL: https://rokad.co/en/docs/kingsbell/architecture-and-design-system > Understand Kingsbell's Shopify theme architecture, design tokens, accessibility baseline, and component boundaries. Kingsbell is an Online Store 2.0 theme built around Shopify-native Liquid, JSON templates, sections, theme blocks, assets, settings, routes, forms, and customer objects. The architecture avoids a separate frontend framework and keeps merchant customization inside Shopify's theme model. ## Runtime directories Kingsbell uses the standard Shopify theme structure: ```text assets/ CSS, JavaScript, and packaged storefront assets blocks/ Reusable theme blocks config/ Global settings schema and saved theme configuration layout/ Storefront document layouts locales/ Storefront and theme-editor translations sections/ Merchant-configurable sections and section groups snippets/ Reusable Liquid rendering units templates/ JSON and Liquid entry templates ``` Repository-only material such as `.design`, QA documents, scripts, and companion contracts is excluded from the Shopify runtime. ## Architectural layers The theme can be understood as five layers: 1. **Foundation** — global tokens, fonts, base styles, layout, metadata, icons, and accessible primitives. 2. **Commerce engine** — products, variants, forms, cart, filters, search, recommendations, and pricing. 3. **Template system** — standard templates plus alternate editorial, archive, commission, and private compositions. 4. **Content system** — blogs, articles, galleries, quotations, interviews, research notes, reusable cards, and flexible blocks. 5. **Companion boundary** — theme-facing member presentation plus a separate specification for secure entitlement enforcement. Keep these layers separate. A visual section should not duplicate cart logic, and a Liquid member gate should not be treated as backend authorization. ## Canonical visual direction Kingsbell's default system is based on: - Obsidian and Alabaster base tones; - restrained champagne accents; - Playfair Display for editorial headings; - Inter for interface and body copy; - sharp geometry and low-contrast outlines; - large negative space; - structured 12-column desktop layouts; - product photography as the primary visual driver; - tonal depth instead of heavy shadows. Merchants can change the global palette, fonts, spacing, radius, buttons, forms, motion, and product-card presentation without replacing the underlying component architecture. ## Colour roles The default colour palette is: | Token | Default | | --- | --- | | Obsidian | `#0A0A0A` | | Alabaster | `#F9F8F6` | | Paper | `#FFFFFF` | | Graphite | `#5F5E5E` | | Outline | `#D8D5D2` | | Champagne | `#C5A059` | | Error | `#BA1A1A` | Theme settings map these palette values into semantic roles such as page background, surface, text, muted text, border, accent, button, button text, and error. Use semantic roles in components. Do not hard-code palette values into new sections unless the value is intentionally local and merchant-configurable. ## Typography The default heading font is Shopify-hosted Playfair Display. The default body font is Shopify-hosted Inter. Global controls include: - heading and body font families; - heading and body scales; - body line height; - heading letter spacing; - label letter spacing; - uppercase button labels. Preserve semantic heading order independently of visual size. A section's styling must not require every large title to be an `h1`. ## Layout tokens Global layout controls include: - maximum page width; - maximum reading width; - desktop and mobile side margins; - grid gutter; - default section spacing; - internal spacing scale; - corner style. The default maximum page width is `1440px`, reading width is `780px`, grid gutter is `32px`, and section spacing is `120px`. Use the shared page-width, grid, spacing, and content-width tokens instead of defining unrelated container widths in each section. ## Theme blocks Reusable blocks in `/blocks` include: - heading; - text; - button; - image; - statistic; - resource card; - spacer; - group. The Flexible content section can render these theme blocks and app blocks. Groups support one nested level of composition. Avoid deeper block trees because they become difficult to understand and maintain in the theme editor. ## Snippets and reusable commerce units Kingsbell uses snippets for repeated behavior such as: - responsive images; - icons; - metadata; - pricing states; - product cards; - option selection; - product forms; - access evaluation; - generated CSS tokens. When extending a reusable behavior, update the shared snippet rather than copying it into multiple sections. Preserve the existing parameter contract or update all call sites together. ## Progressive enhancement Core content and commerce should remain understandable before JavaScript enhances it. Examples: - tabbed content is readable as sequential panels without JavaScript; - reading progress is optional enhancement; - copy-link behavior includes a fallback; - Ajax filters and cart actions should not erase Shopify's underlying routes and forms; - reveal effects are disabled or reduced for visitors who request reduced motion. ## Accessibility baseline The foundation includes: - a skip link; - focus-visible treatment; - a focusable main content target; - semantic form controls; - reduced-motion behavior; - responsive image alt handling; - keyboard-aware tabs and navigation; - no positive `tabindex` or autofocus in validated theme code. Every new component must preserve keyboard access, visible focus, sensible source order, and readable states at browser zoom. ## Theme-editor lifecycle Shopify can reload sections independently inside the theme editor. Component JavaScript must support: - initial page load; - section load and unload; - block selection where relevant; - repeated initialization without duplicate listeners; - DOM replacement after Ajax rendering. Do not assume a component is initialized only once per page. ## Design-reference boundary The `.design` directory contains prototypes and screenshots used to derive production sections and templates. It is reference material only. Do not: - link storefront assets from `.design`; - import prototype JavaScript into the theme; - depend on prototype route structures; - treat screenshots as implementation specifications when they conflict with Shopify behavior, accessibility, or merchant configurability. The production theme is the source of truth for runtime behavior. --- ## [Documentation / kingsbell] Customization and theme settings Canonical URL: https://rokad.co/en/docs/kingsbell/customization-and-settings > Configure Kingsbell's brand, colours, typography, layout, motion, buttons, forms, product cards, theme blocks, and structured sections. Kingsbell exposes global settings for the visual system and section-level settings for page composition. Use global settings for consistent store-wide decisions and section settings for local content and layout choices. ## Brand settings The Brand group includes: - primary logo; - inverse logo; - logo width from `80px` to `320px`; - favicon. Provide SVG or high-resolution raster artwork with sufficient contrast. Test the primary and inverse logos against the actual header backgrounds used by the selected templates. When no logo is configured, Kingsbell can fall back to a text wordmark. ## Colours The theme defines a palette and semantic colour roles. Default palette values: | Palette entry | Default | | --- | --- | | Obsidian | `#0A0A0A` | | Alabaster | `#F9F8F6` | | Paper | `#FFFFFF` | | Graphite | `#5F5E5E` | | Outline | `#D8D5D2` | | Champagne | `#C5A059` | | White | `#FFFFFF` | | Error | `#BA1A1A` | Semantic roles include: - page background; - raised surface; - alternate surface; - primary text; - muted text; - borders; - accent; - primary button; - primary button text; - error. Change semantic roles rather than editing component CSS. After changing colours, review text contrast, focus rings, form errors, disabled states, sale prices, badges, overlays, and inverse headers. ## Typography Global typography settings include: - heading font; - body font; - heading scale from 80% to 140%; - body scale from 90% to 120%; - body line height from 130% to 190%; - heading letter spacing; - label letter spacing; - uppercase button labels. Defaults are Playfair Display for headings and Inter for body copy. Large heading scales can cause wrapping in product titles, navigation, buttons, and narrow mobile layouts. Review the longest real content rather than placeholder text. ## Layout and motion Global layout controls include: | Setting | Range or options | Default | | --- | --- | --- | | Maximum page width | `1000–1600px` | `1440px` | | Maximum reading width | `640–1040px` | `780px` | | Desktop side margin | `24–120px` | `80px` | | Mobile side margin | `16–40px` | `24px` | | Grid gutter | `16–48px` | `32px` | | Section spacing | `72–168px` | `120px` | | Internal spacing scale | `80–140%` | `100%` | | Corner style | Sharp, subtle, soft, rounded | Sharp | | Motion intensity | Subtle, moderate, expressive | Subtle | Additional controls enable motion effects, smooth anchor scrolling, and reduced-motion support. Reduced-motion support should remain enabled. It respects a visitor's operating-system preference even when motion effects are enabled for other visitors. ## Buttons and forms Button controls include: - height from `44px` to `64px`; - horizontal padding from `16px` to `40px`; - border width from `1px` to `3px`; - fade, invert, or shift hover style; - uppercase or natural-case labels. Form controls include underline or boxed input styles and a configurable focus-ring width. Do not reduce button height below a comfortable pointer target. After changing hover or focus styling, test keyboard focus separately from pointer hover. ## Product cards Global product-card controls include: - portrait, square, or image-adaptive media ratio; - text alignment; - no hover, subtle zoom, or card lift; - optional currency codes; - outline, solid, or text-link quick add. Product-card settings affect collection, search, recommendation, and other reusable card grids. Review every context after changing them. Use currency codes when stores serve markets where the currency symbol alone is ambiguous. ## Flexible content The Flexible content section renders reusable theme blocks and Shopify app blocks. Available theme blocks include: - heading; - text; - button; - image; - statistic; - resource card; - spacer; - group. Groups support one nested level. This is enough for practical compositions while keeping the theme editor understandable. Use Flexible content for structured landing pages, reports, service pages, campaign pages, member resources, and other compositions that do not require a dedicated section. ## Specification table The Specification table section presents structured labels and values. It is suitable for: - product or material specifications; - dimensions; - service inclusions; - policy facts; - report metadata; - technical attributes. Keep labels concise and avoid embedding complex rich text inside table values. On mobile, verify that long labels and URLs wrap without horizontal scrolling. ## Tabbed content Tabbed content remains readable as sequential panels without JavaScript. JavaScript adds: - selected-tab state; - panel visibility; - ARIA relationships; - keyboard navigation; - theme-editor block selection behavior. Use tabs only for closely related alternatives. Do not hide essential legal, shipping, safety, or accessibility information behind a tab that visitors may overlook. ## Reusable card grids and metaobjects The reusable-card section can render manual blocks or a list of `kingsbell_content_card` metaobjects. Use metaobjects when records need centralized management and reuse. Example records include resources, people, reports, services, principles, or linked content. A metaobject definition should follow the repository's `METAOBJECTS.md` contract. Field handles and types must match the Liquid implementation. Use manual cards when content appears only once or when a merchant does not need centralized records. ## Page templates for structured content Kingsbell includes: ```text page.flexible.json page.specifications.json page.content-library.json ``` - `page.flexible.json` is a general block-based composition. - `page.specifications.json` prioritizes structured facts and explanatory content. - `page.content-library.json` is suitable for reusable card or resource collections. Assign the template to a Shopify page, then configure its sections in the theme editor. ## Dynamic sources Where Shopify allows dynamic sources, connect section settings to product, collection, page, article, metafield, or metaobject data rather than duplicating values manually. Before using a dynamic source: - confirm the source type matches the setting; - define fallback behavior for missing data; - test resources with and without the value; - avoid exposing internal or confidential metafields; - verify translations and market-specific content. ## Safe customization rules Prefer, in order: 1. theme settings; 2. section and block settings; 3. JSON-template composition; 4. reusable snippets or blocks; 5. new sections; 6. global CSS or JavaScript changes only when the behavior truly applies everywhere. Avoid editing shared commerce behavior for a purely visual requirement. Avoid copying sections when a template-level configuration can produce the required result. ## Configuration review checklist After a substantial theme-editor change: - save and reload the editor; - preview representative products, collections, pages, blogs, and articles; - test mobile and desktop; - test keyboard focus and reduced motion; - verify empty and missing-content states; - review product cards in every context; - confirm forms, cart, filters, search, and app blocks still work; - export or duplicate the configured theme before a high-risk change. --- ## [Documentation / kingsbell] Editorial and structured content Canonical URL: https://rokad.co/en/docs/kingsbell/editorial-and-structured-content > Build journals, essays, interviews, visual stories, research pages, galleries, and reusable structured content with Kingsbell. Kingsbell extends Shopify's blog and article system into a structured editorial layer. Shopify remains the source of truth for blogs, articles, authors, tags, publication dates, excerpts, and article bodies; JSON-template sections add richer presentation around that native content. ## Blog templates Kingsbell includes: ```text blog.editorial.json blog.index.json ``` `blog.editorial.json` is a magazine-style journal with a lead story and supporting articles. `blog.index.json` is a chronological editorial index. Both templates support: - tag navigation; - pagination; - article metadata; - excerpts; - calculated reading time. The standard `blog.json` template remains available for simpler publishing needs. ## Article templates Kingsbell includes: ```text article.editorial.json article.interview.json article.visual.json article.research.json ``` The standard `article.json` template also remains available. ### Editorial article Use `article.editorial.json` for long-form essays, features, announcements, profiles, and narrative articles. ### Interview article Use `article.interview.json` for structured question-and-answer content. The dialogue section can distinguish speakers and maintain a readable sequence. ### Visual article Use `article.visual.json` when photography, image sequences, video, or galleries carry most of the narrative. ### Research article Use `article.research.json` for evidence-led writing, indexed observations, references, methods, or documented findings. A template changes composition, not the underlying article object. Keep the canonical title, publication date, author, excerpt, tags, and article body in Shopify. ## Editorial sections The editorial system includes: - editorial journal index; - editorial article shell; - pull quotation; - image or Shopify-hosted video feature; - asymmetrical image gallery; - contributor profile; - related reading; - structured dialogue; - indexed notes and references; - reusable article comments; - scoped editorial stylesheet loader. Use sections to compose story-specific modules around the native article body. ## Article body and modules Article bodies continue to use Shopify's article editor. This preserves editing, feeds, search, and standard article behavior. Use JSON-template sections for modules that need structured settings, such as: - a full-width lead image; - a pull quote; - a contributor profile; - a multi-image gallery; - a conversation transcript; - numbered notes or references; - related reading. Do not convert every paragraph into a theme section. Excessive sectionization makes articles slow to author and difficult to migrate. ## Reading time Kingsbell estimates reading time from article content at approximately 220 words per minute. Treat the result as an estimate. Image-led stories, code, tables, interviews, and multilingual content may take more or less time than the displayed value suggests. ## Reading progress Article reading progress is progressively enhanced with JavaScript. The article remains fully readable when JavaScript is unavailable. Any customization must preserve: - correct progress bounds; - no obstruction of article controls; - reduced-motion behavior; - section reload behavior in the theme editor. ## Excerpts and standfirsts An article excerpt can be displayed beneath the title as a standfirst. Write excerpts as editorial summaries rather than repeating the opening paragraph. A useful standfirst should explain: - what the article covers; - why it matters; - what the reader will learn. ## Tags and related reading Blog templates expose tag navigation. Related reading can match the current article's first tag. Use a deliberate tag taxonomy. Avoid creating near-duplicate tags that differ only in case, punctuation, or pluralization. Tag-based related reading is a discovery aid, not a guaranteed semantic recommendation. Merchants should review the resulting articles in preview. ## Images and video Use Shopify-hosted images and video. For every media section: - provide useful alt text for informative images; - use empty alt text for intentionally decorative images; - provide poster or fallback imagery where appropriate; - test portrait, landscape, and unusually wide media; - check focal points on mobile; - avoid autoplay with sound; - respect reduced-motion preferences. The asymmetrical gallery is designed for editorial rhythm, but source order must still make sense for keyboard and assistive-technology users. ## Pull quotations Pull quotes should reinforce an argument or memorable statement, not duplicate large sections of nearby text. Keep attribution explicit when the quotation comes from another person or source. A visual pull quote is not a substitute for citations in research-oriented content. ## Interviews and dialogue The structured dialogue section is suitable for interviews, conversations, and question-and-answer formats. Use consistent speaker names and keep each response in source order. Do not rely only on colour or alignment to identify speakers. ## Notes and references The indexed notes section can present evidence, observations, sources, or endnotes in a structured list. For research-oriented articles: - identify authors and organizations accurately; - include stable source links when available; - distinguish evidence from commentary; - record publication or access dates when relevant; - avoid placing essential references only in images. Kingsbell formats references but does not validate their accuracy. ## Contributor profiles Contributor profiles can include a name, role, image, biography, and link. Keep biographies concise and ensure profile links are intentional and safe. When multiple contributors are involved, choose a consistent representation across the journal. ## Reusable structured content Kingsbell includes a reusable card grid that can use manual blocks or a `kingsbell_content_card` metaobject list. Metaobjects are appropriate for content reused across several pages, such as: - resources; - services; - reports; - collections of links; - people; - principles; - specifications. Use manual blocks for one-off content. Use metaobjects when the same record must be managed centrally and rendered in multiple places. ## Optional sections Placeholder-dependent editorial sections are disabled in JSON templates by default where empty output would be misleading. Before enabling a section: 1. provide its required content; 2. verify heading hierarchy; 3. test mobile layout; 4. check image alt text; 5. test article pagination, tags, and related reading; 6. save and reload the template in the theme editor. ## Publishing checklist Before publishing an article: - confirm title, author, date, excerpt, and tags; - select the appropriate template; - review article-body formatting; - configure optional editorial sections; - check links and references; - verify images and alt text; - preview desktop and mobile layouts; - test copy-link and reading-progress enhancements; - verify related reading; - review the final page without editor placeholders. --- ## [Documentation / kingsbell] Getting started with Kingsbell Canonical URL: https://rokad.co/en/docs/kingsbell/getting-started > Understand Kingsbell, its release status, Shopify requirements, and the safest path from installation to a production storefront. Kingsbell is a configurable editorial-commerce theme for Shopify, developed by Rokad. It combines a complete Online Store 2.0 storefront with image-led layouts, structured editorial publishing, advanced merchant controls, and an optional theme-facing private-member experience. The current repository package version is `0.11.0`. Kingsbell remains a pre-`1.0.0` release that is being hardened for its first Shopify Theme Store submission. Repository-level checks and Shopify-native package generation are implemented, but production approval still requires development-store, browser, accessibility, performance, and real commerce-flow validation. ## What Kingsbell includes Kingsbell provides: - standard Shopify storefront templates for products, collections, cart, search, pages, blogs, articles, contact, password, and error states; - Ajax cart, predictive search, native filtering and sorting, product recommendations, pickup availability, and dynamic checkout support; - editorial, archive, commission, and private layout families; - structured journal templates for essays, interviews, visual stories, and research-oriented articles; - reusable theme blocks and structured-content sections; - global controls for colour, typography, spacing, buttons, forms, motion, and product cards; - member-facing presentation gates and account-aware sections; - Theme Check, static auditing, packaging, Lighthouse workflow scaffolding, and manual release procedures. ## Requirements For local development you need: - Node.js 20 or newer; - Shopify CLI with theme support; - access to a Shopify development store; - permission to install, preview, and edit themes in that store. Install Shopify CLI: ```bash npm install --global @shopify/cli @shopify/theme ``` Confirm the installation: ```bash shopify version node --version ``` ## Recommended adoption path Use this sequence when adopting Kingsbell: 1. Clone or download the Kingsbell repository. 2. Run the repository checks before editing the theme. 3. Connect Shopify CLI to a dedicated development store. 4. Preview the unmodified theme and verify the baseline templates. 5. Configure brand, colours, typography, layout, and product-card defaults. 6. Build navigation, footer, homepage, product, collection, and editorial templates in the theme editor. 7. Add representative catalog, customer, B2B, article, and order data. 8. Complete the development-store QA matrix. 9. Generate a package only after the selected configuration passes review. 10. Keep a tested rollback package before publishing or replacing a live theme. ## First local commands From the theme repository: ```bash npm run check npm run dev -- --store your-store.myshopify.com npm run package ``` `npm run check` runs Shopify Theme Check. `npm run dev` starts Shopify's remote development preview. `npm run package` creates a Shopify-installable theme archive from supported theme directories. The release workflow also contains a deterministic repository audit that validates schemas, JSON templates, accessibility hazards, unsafe links, route usage, and asset budgets. ## Theme directories Storefront code is restricted to Shopify-supported theme directories: ```text assets/ blocks/ config/ layout/ locales/ sections/ snippets/ templates/ ``` Repository-only files, design references, QA documents, scripts, and companion specifications are excluded from Shopify push and package boundaries. ## Choose a starting template Kingsbell includes a standard storefront and four visual directions: | Direction | Best suited to | | --- | --- | | Standard | Conventional commerce with restrained editorial styling. | | Editorial | Campaign-led stores, launches, and product storytelling. | | Archive | Catalogues, collections, editions, and chronology-led presentation. | | Commission | Bespoke, made-to-order, consultation, and service-led commerce. | | Private | Invitation-led or member-facing presentation with separate enforcement requirements. | Start with the standard templates when validating commerce behavior. Introduce alternate templates after products, variants, filters, cart, search, and checkout entry points are confirmed. ## Important security boundary Kingsbell can conditionally hide restricted storefront branches from unauthorised visitors. Liquid presentation controls do not secure product publication, search indexes, Storefront API data, cart APIs, permanent files, or checkout. Private commerce must be enforced with Shopify-native catalog and publication controls, B2B company assignments, Shopify Functions where applicable, and/or a companion application that performs server-side authorization. ## Production readiness Do not treat successful theme packaging as production approval. Before publishing, complete: - development-store testing with representative data; - keyboard and screen-reader review; - responsive and cross-browser review; - real product, variant, cart, discount, market, account, and checkout flows; - Lighthouse performance and accessibility testing; - theme-editor save and section-reordering tests; - private-member authorization tests where those templates are used; - rollback verification. Continue with the installation and development guide before changing theme code. --- ## [Documentation / kingsbell] Installation and local development Canonical URL: https://rokad.co/en/docs/kingsbell/installation-and-development > Install Kingsbell, connect Shopify CLI, run local previews, validate changes, and package the theme safely. Kingsbell uses Shopify CLI for development, validation, remote preview, and packaging. Use a dedicated Shopify development store rather than an active production store while building or testing the theme. ## Install prerequisites Kingsbell requires Node.js 20 or newer and Shopify CLI with theme support. ```bash node --version npm install --global @shopify/cli @shopify/theme shopify version ``` Clone the repository and enter the project directory: ```bash git clone https://github.com/rokadhq/kingsbell.git cd kingsbell ``` The repository does not require an application dependency installation for normal Liquid development. The `package.json` scripts wrap Shopify CLI commands. ## Connect a development store Start the remote development server: ```bash npm run dev -- --store your-store.myshopify.com ``` Shopify CLI will request authentication when needed and create or reuse a development theme. Keep development and staging stores separate from production data whenever possible. An example environment file is provided as `shopify.theme.toml.example`. Copy it only when you need named CLI environments, and never commit store passwords, Admin API tokens, customer data, or private application credentials. ## Core commands ```bash npm run dev -- --store your-store.myshopify.com npm run check npm run package ``` | Command | Purpose | | --- | --- | | `npm run dev` | Starts Shopify's development preview and synchronizes local changes. | | `npm run check` | Runs Theme Check using the repository configuration. | | `npm run package` | Creates a Shopify theme ZIP from supported theme directories. | The CI pipeline also runs a deterministic static audit before packaging. ## Development workflow Use a reviewable branch for each change: ```bash git checkout -b theme/example-change npm run check npm run dev -- --store your-store.myshopify.com ``` While previewing: 1. test the changed section in the theme editor; 2. save and reload the template; 3. verify desktop and mobile layouts; 4. use keyboard-only navigation; 5. test with and without JavaScript where progressive enhancement is expected; 6. test empty, loading, error, sold-out, sale, and high-variant states where relevant; 7. run Theme Check again before committing. ## Shopify-supported runtime boundary Kingsbell storefront code belongs only in: ```text assets/ blocks/ config/ layout/ locales/ sections/ snippets/ templates/ ``` Do not place runtime dependencies in repository documentation, QA folders, prototype directories, or companion specifications. `.shopifyignore` excludes repository-only material from Shopify CLI push and pull operations. The `.design` directory is visual reference material. It is not part of the storefront runtime and should not be imported or linked from Liquid templates. ## Editing templates and sections Kingsbell uses Shopify JSON templates. Prefer merchant-configurable composition over hard-coded page structures. When adding a section: - include valid section schema JSON; - provide usable defaults and presets when the section is merchant-addable; - use Shopify routes, forms, assets, and image helpers; - keep optional content conditional; - preserve keyboard focus and semantic heading order; - avoid parser-blocking external scripts; - keep JavaScript progressively enhanced and scoped to the component; - respect reduced-motion preferences. When adding a template: - reference existing section types exactly; - keep section ordering explicit; - provide a stable baseline when optional content is missing; - verify the template can be opened and saved in the theme editor. ## Working with assets Use Shopify-hosted assets and image filters rather than fixed external URLs. For images: - provide meaningful alt text or an intentional empty alt for decorative media; - use responsive image widths and sizes; - avoid shipping unnecessarily large source files; - validate focal points and cropping across breakpoints. For JavaScript: - defer non-critical behavior; - avoid global state unless the behavior is genuinely global; - reinitialize correctly after theme-editor section reloads; - remove event listeners when components are disconnected; - preserve a usable non-JavaScript state. ## Theme Check and static audit Theme Check is configured at strict suggestion-level enforcement in the release workflow. The static audit validates additional repository constraints, including: - required Shopify files; - JSON and schema syntax; - template section references; - accessibility hazards such as positive `tabindex`, `autofocus`, and zoom restrictions; - unsafe `_blank` links and insecure HTTP references; - hard-coded core storefront routes; - unsupported Sass or robots patterns; - JavaScript and CSS budgets; - product app-block support. Treat warnings as implementation work, not as release notes to ignore. ## Package the theme Create an installable archive only after checks pass: ```bash npm run check npm run package ``` The Phase 8 release workflow generates `Kingsbell-0.8.0.zip`. Confirm the package version before distribution and install the ZIP into a clean development store before approving it. Packaging proves that Shopify CLI can assemble the theme. It does not prove that merchant configuration, browser behavior, performance, accessibility, customer accounts, B2B context, or checkout flows are correct. ## Secrets and customer data Never commit: - Shopify passwords or access tokens; - Admin API, Storefront API, or Customer Account API credentials; - private application secrets; - customer exports or order data; - development-store cookies; - production theme settings containing confidential content. Use Shopify's credential mechanisms and repository secret storage for CI integrations. --- ## [Documentation / kingsbell] Member experience and private commerce Canonical URL: https://rokad.co/en/docs/kingsbell/member-and-private-commerce > Configure Kingsbell's customer-aware presentation while enforcing private catalog and commerce rules outside the theme. Kingsbell includes a theme-facing member experience for signed-in customers, tagged members, and Shopify B2B customers. These capabilities control presentation in Liquid. They do not, by themselves, secure products, APIs, files, carts, or checkout. ## Supported presentation states The shared access evaluator supports: - public access; - any signed-in customer; - a required customer tag; - an authenticated B2B customer; - customer tag or B2B context. A section or private template can select the relevant presentation rule and render either member content or a visitor-facing gate. ## Theme capabilities Kingsbell provides: - a reusable Member gate section; - support for Phase 6 theme blocks and app blocks inside the gate; - a signed-in member dashboard; - customer identity and order summary presentation; - B2B company context; - account, profile, address, order, and logout routes; - recent order presentation; - a Shopify-native member-access request form; - an account-aware header link; - customer-aware invitation routing; - optional gates in private product and collection sections. ## Assignable templates Kingsbell includes: ```text page.member-hub.json page.member-resources.json page.member-request.json product.private.json collection.private.json ``` The private product and collection templates default to a `member` customer tag or an authenticated B2B customer. Merchants can change presentation settings, but enforcement must remain aligned with the actual catalog and entitlement model. ## What the Liquid gate hides When access is not satisfied, the private product and collection sections can avoid rendering restricted branches such as: - product media; - descriptions; - prices; - variants; - collection grids; - filters; - quick add; - buy forms. This reduces accidental disclosure in the rendered page. It is not a complete authorization system. ## What the Liquid gate does not secure A theme gate does not secure: - product publication; - Shopify search indexes; - Storefront API responses; - cart APIs; - direct product or variant identifiers; - permanent files or media URLs; - checkout; - discounts; - inventory allocation; - customer or company entitlements in backend systems. Do not publish confidential products and assume a hidden Liquid branch makes them private. ## Enforcement options Depending on the store model, use one or more of: - Shopify product publication controls; - Shopify catalogs and market assignments; - B2B company and company-location assignments; - customer account identity; - Shopify Functions for applicable validation or discount logic; - a companion application with server-side authorization; - controlled file delivery for protected assets; - backend audit logs and entitlement expiry. The visible theme state and the authoritative commerce state must agree. ## Identity authority Kingsbell treats Shopify customer accounts as the identity authority. The theme uses Shopify's customer context and official account routes rather than maintaining a separate password system in Liquid. Relevant Shopify primitives include: - the global `customer` object; - customer tags; - `customer.b2b?`; - current company and company location; - customer order data; - storefront login and account routes; - the `` header component. A companion application may maintain richer entitlement records, but it should link them to Shopify customer identity. ## Customer tags Customer tags are useful as a storefront-readable mirror of a membership state. They are not an ideal sole source of complex entitlements. When using tags: - define exact tag names and casing; - avoid using a tag for multiple unrelated programs; - remove or update tags when membership expires or is revoked; - keep backend entitlement records authoritative when approval workflows are complex; - test customers with no tags, the required tag, unrelated tags, and multiple tags. ## B2B context Kingsbell can recognize authenticated B2B customers and expose company context in member presentation. Test: - a direct customer; - a B2B customer without an active company location; - a B2B customer with the expected company and location; - a customer belonging to more than one relevant context where supported; - catalog assignment and product availability; - checkout under the correct company context. Theme presentation must not override Shopify's actual B2B catalog rules. ## Member dashboard The dashboard can present: - customer name and account identity; - order count; - account value summary where configured; - B2B company context; - account navigation; - recent orders. Display only data available through Shopify's supported Liquid customer context. Richer account data belongs in customer account UI extensions or a companion application. ## Member access requests The member request template uses a Shopify contact form. It collects a request; it does not automatically approve access. Define an operational workflow for: 1. receiving the request; 2. verifying the requester; 3. approving or rejecting access; 4. updating the authoritative entitlement; 5. mirroring the required tag or metafield where appropriate; 6. notifying the customer; 7. recording expiry, suspension, or revocation. Do not place confidential approval logic in client-side JavaScript. ## Companion application contract The Kingsbell repository includes `MEMBER-COMPANION.md` and `companion/member-entitlement.schema.json`. The companion specification covers: - entitlement status and scopes; - customer-tag and metafield mirrors; - admin workflows; - theme app blocks; - customer account UI extensions; - backend authorization; - audit requirements; - approval, expiry, suspension, and revocation; - B2B and direct-customer paths. Treat the JSON schema as a data-contract starting point. Application authorization must still validate every protected operation server-side. ## Recommended entitlement states A practical entitlement lifecycle includes: - requested; - under review; - approved; - active; - expired; - suspended; - revoked; - rejected. The theme usually needs only a simplified active/inactive mirror. Administration and backend enforcement need the full state, timestamps, actor, reason, scopes, and audit history. ## Private-commerce test matrix Before launch, test: - signed-out visitor; - signed-in customer without access; - tagged member; - expired or revoked member; - B2B customer with the correct catalog; - customer with unrelated tags; - direct URLs to products, collections, search, media, cart, and checkout; - Storefront API access where enabled; - account login, logout, and redirect behavior; - request-form submission; - entitlement changes during an active session; - rollback when the companion service is unavailable. A private template is ready only when presentation and authoritative enforcement both pass. --- ## [Documentation / kingsbell] Quality assurance and release Canonical URL: https://rokad.co/en/docs/kingsbell/quality-assurance-and-release > Run Kingsbell's automated checks, development-store validation, Lighthouse workflow, packaging controls, and release checklist. Kingsbell `0.8.0` is structured as a release candidate. Repository-level validation and Shopify-native packaging are implemented, but a production release still requires authenticated development-store and browser testing. ## Automated quality gates The release workflow combines: - a deterministic static theme audit; - strict Shopify Theme Check; - JSON and schema validation; - Shopify-native theme packaging; - an opt-in Shopify Lighthouse workflow; - manual development-store and release procedures. A passing package job does not replace functional, accessibility, performance, account, B2B, or checkout testing. ## Static theme audit `scripts/qa-theme.mjs` validates: - required Shopify theme files; - JSON syntax across templates, locales, and configuration; - JSON section ordering and section-type references; - section and theme-block schema JSON; - positive `tabindex`; - `autofocus` usage; - browser zoom restrictions; - raw images without alt attributes; - parser-blocking external scripts; - unsafe `_blank` links; - insecure HTTP references; - hard-coded core storefront routes; - Sass and unsupported robots template usage; - JavaScript and CSS asset budgets; - required layout objects, language, skip link, and focusable main content; - product app-block support. The audit writes: ```text artifacts/theme-qa-report.json ``` CI uploads the report for review. ## Theme Check Theme Check is enforced at suggestion severity in the release workflow. Run it locally: ```bash npm run check ``` Review every diagnostic. Suppression should be rare, scoped, documented, and justified by verified Shopify behavior. ## Package generation After static validation and Theme Check succeed, package the theme: ```bash npm run package ``` The Phase 8 workflow generates: ```text Kingsbell-0.8.0.zip ``` Only Shopify theme directories are included by the packaging command. Repository documentation, QA files, design references, scripts, and companion contracts are outside the package boundary. Install the generated ZIP into a clean development store. Do not approve the exact package unless the installed artifact—not only the branch preview—passes the release checks. ## Lighthouse CI The repository includes a Shopify Lighthouse workflow with minimum scores of: - performance: `0.60`; - accessibility: `0.90`. The job is controlled by the repository variable: ```text ENABLE_SHOPIFY_LIGHTHOUSE ``` It remains skipped until a dedicated benchmark development store and required credentials are configured. A skipped Lighthouse job is not a passed performance or accessibility test. Use representative pages for benchmarking: - homepage; - collection with filters; - product with multiple media items and variants; - cart; - search results; - editorial article; - member page where applicable. Record the tested URL, theme package, store data, device profile, and date so results can be reproduced. ## Manual QA documents The Kingsbell repository includes: - `QA-MATRIX.md` — functional, accessibility, responsive, browser, performance, SEO, commerce, editorial, and member-state coverage; - `DEVELOPMENT-STORE-QA.md` — store setup and execution procedure; - `RELEASE-CHECKLIST.md` — release, packaging, security, merchant configuration, publication, and rollback controls. Use these documents as release records, not informal reminders. ## Development-store setup A useful test store should contain: - products with single and multiple variants; - sale, sold-out, unavailable, and unit-price products; - multiple collections and native filters; - product media in varied aspect ratios; - pickup availability where supported; - articles for every editorial template; - menus with multiple navigation levels; - a direct customer; - a tagged member; - a B2B customer and company context where applicable; - representative orders; - markets, currencies, discounts, and shipping rules used by the target store; - required app blocks and metaobjects. Do not validate only with ideal placeholder content. ## Functional testing Verify at minimum: - navigation, search, predictive search, and customer-account links; - product media, variants, quantity, errors, and add to cart; - dynamic checkout configuration; - cart drawer and cart page synchronization; - collection and search filters, sorting, pagination, and history; - recommendations and app blocks; - newsletter, contact, password, and member-request forms; - blog tags, article templates, reading progress, galleries, and related reading; - template assignment and theme-editor save behavior; - member presentation and authoritative private-commerce enforcement. ## Accessibility testing Automated checks are only the first layer. Manually verify: - keyboard access to all controls; - logical focus order; - visible focus indicators; - skip-link behavior; - heading structure; - labels and errors for forms; - menu, dialog, drawer, tabs, predictive search, and variant-picker semantics; - alt text and decorative-image handling; - colour contrast; - zoom and reflow; - reduced-motion behavior; - screen-reader announcements for dynamic cart and validation states. Test with at least one desktop and one mobile screen reader before production approval. ## Responsive and browser testing Review representative pages at narrow mobile, wide mobile, tablet, laptop, and large desktop widths. Test current supported versions of major browsers used by the target customers. Include Safari on iOS because media, sticky layout, focus, and viewport behavior can differ materially from Chromium browsers. Verify: - navigation and drawers; - image crops and focal points; - long titles and translated text; - filters and option selectors; - sticky elements; - forms and virtual keyboards; - tables, galleries, and tabs; - account and checkout entry points. ## Performance review In addition to Lighthouse scores, review: - largest images and video; - JavaScript and CSS totals; - third-party app scripts; - font loading; - layout shifts; - cart, predictive search, filter, and recommendation response behavior; - repeated initialization in the theme editor; - mobile network performance. A visually empty test store produces misleading performance results. Use realistic content and app integrations. ## SEO and metadata Verify: - page titles and meta descriptions; - canonical URLs; - product, collection, article, and organization structured data where applicable; - social preview metadata; - heading hierarchy; - indexability of intended public pages; - redirects and 404 behavior; - pagination and filtered URLs; - no accidental exposure of content intended to be private. Theme controls cannot make a published product private from every Shopify surface. ## Release criteria Do not advance Kingsbell to `1.0.0` until: 1. the packaged theme is installed into a clean development store; 2. applicable QA matrix rows are signed off; 3. Shopify Lighthouse CI passes against the benchmark store; 4. private catalog and checkout enforcement are verified independently from Liquid; 5. a tested rollback package exists. ## Rollback Before publication: - retain the currently live theme; - record its theme ID and configuration state; - save the approved Kingsbell package; - define who can publish or roll back; - test activation of the previous theme; - document any app, metafield, metaobject, or catalog changes that must also be reversed. A theme rollback may not undo backend configuration changes. ## Current validation boundary The repository records completion of deterministic static audit, strict Theme Check, schema validation, and Shopify-native package generation. The following require a configured store and must be recorded separately: - Shopify authentication and remote theme interaction; - interactive browser tests; - theme-editor save tests; - real customer, order, market, B2B, and checkout flows; - Lighthouse measurements; - BrowserStack or physical-device tests. Release notes must distinguish completed checks from tests that were skipped or unavailable. --- ## [Documentation / kingsbell] Storefront and commerce Canonical URL: https://rokad.co/en/docs/kingsbell/storefront-and-commerce > Configure Kingsbell's product, collection, cart, search, recommendation, and navigation capabilities without breaking Shopify-native behavior. Kingsbell's commerce layer is built on Shopify-native product, variant, cart, search, collection, customer, and recommendation primitives. Alternate visual templates reuse this commerce engine rather than implementing separate purchasing logic. ## Product presentation The reusable product system supports: - responsive product media; - sale and sold-out states; - currency and unit-price display; - SKU and inventory information; - pickup availability; - product options and variant selection; - high-variant products using option-value IDs; - combined-listing-aware option URLs; - quantity input; - Ajax add to cart; - dynamic checkout buttons; - product-form errors and loading states; - accordions and product information blocks; - Shopify app blocks; - complementary and related products. Use the standard product template to validate data and behavior before applying an alternate product template. ## Product options and variants Kingsbell renders options from `product.options_with_values` and uses Shopify option-value identifiers where available. This is important for products with many variants and for combined listings. When testing a product, include: - a single-variant product; - a product with multiple option groups; - unavailable option combinations; - sold-out variants; - products with more than one media item; - products with unit pricing; - products with pickup availability; - a combined-listing scenario when the store uses that feature. Do not replace Shopify option URLs or variant identifiers with text-only matching. ## Product forms Product forms support Ajax submission and Shopify's normal purchase flow. A product section should always preserve: - the selected variant ID; - quantity; - selling-plan data when applicable; - validation errors; - loading and disabled states; - dynamic checkout configuration; - app blocks placed by merchants. When customizing the button or form layout, keep the native form contract intact. ## Pricing The shared price renderer handles: - regular price; - compare-at sale price; - sold-out presentation; - currency-code display when enabled; - unit pricing. Use the shared renderer on product cards, product pages, search results, and recommendations to prevent inconsistent price states. ## Product cards Reusable cards include: - responsive primary media; - optional secondary-image hover; - badges; - price rendering; - availability state; - quick add; - merchant-configurable media ratio, alignment, hover style, and quick-add style. Quick add must not bypass option selection for products that require a variant choice. Test single-variant and multi-variant products separately. ## Collections Collection templates support: - collection imagery and description; - native storefront filters; - sorting; - pagination; - reusable product cards; - Ajax updates; - browser-history updates; - empty states. The collection banner is separated from the filter and product-grid section, allowing merchants to change the page introduction without replacing commerce logic. ## Filtering and sorting Kingsbell uses Shopify's native filter data. Ajax enhancement updates the collection or search result area while preserving URL state. Validate: - filter combinations; - active-filter removal; - price range inputs; - sorting changes; - pagination after filtering; - browser back and forward navigation; - copied filtered URLs; - no-JavaScript behavior; - empty result sets. Do not invent filter values in theme code. Product taxonomy, options, availability, price, and metafield filters must come from Shopify's storefront filter configuration. ## Cart drawer and cart page Kingsbell includes a cart drawer and a full cart page. Ajax quantity and removal actions synchronize affected sections using Shopify bundled section rendering. Test: - adding from product forms and quick add; - opening the drawer after add; - changing quantity; - removing an item; - cart count updates; - line-item properties; - selling plans when used; - unavailable inventory responses; - empty cart; - cart-page fallback when JavaScript is unavailable. The theme must not calculate authoritative totals in JavaScript. Display the cart data returned by Shopify. ## Search and predictive search Predictive search can return: - products; - suggested queries; - collections; - pages; - articles. The search template supports native filters, sorting, pagination, and Ajax result updates. Validate keyboard navigation, escaped search terms, no-result states, slow responses, and mobile behavior. Search results may expose published products even when a theme-facing member gate hides another template; secure private catalogs with Shopify publication and entitlement controls. ## Recommendations Related products are loaded through Shopify's Recommendations API. Recommendation sections should tolerate: - no recommendations; - fewer products than the configured limit; - unavailable products; - section reloads in the theme editor; - delayed responses. Recommendations are merchandising, not access control. ## Navigation and customer entry points Kingsbell supports multi-level desktop and mobile navigation, search, cart access, and Shopify's current customer-account component. Header behavior includes: - optional sticky positioning; - brand logo or wordmark; - desktop navigation; - mobile navigation; - search entry; - cart entry; - account or member-aware link. Build menus in Shopify navigation and assign them through section settings. Avoid hard-coded storefront URLs; use Shopify route objects and link objects. ## App compatibility Product templates include app-block support. The Flexible content section can also render app blocks. Before approving an app integration: - place the app block in the theme editor; - verify save and reload behavior; - test mobile and desktop layouts; - confirm scripts are not duplicated after section reload; - review performance and privacy impact; - confirm the app does not override cart, variant, or customer behavior unexpectedly. ## Commerce regression checklist After changing shared snippets, product sections, cards, cart JavaScript, filters, or search, retest: - product options and availability; - add to cart; - cart drawer and cart page; - pricing and currency display; - collection filters and sorting; - search and predictive search; - recommendations; - app blocks; - customer-account routes; - keyboard and reduced-motion behavior. Alternate templates are considered valid only when these shared commerce flows continue to work. --- ## [Documentation / kingsbell] Templates and layout variants Canonical URL: https://rokad.co/en/docs/kingsbell/templates-and-layout-variants > Choose and configure Kingsbell's standard, editorial, archive, commission, and private Shopify templates. Kingsbell provides a complete standard storefront plus alternate layout families derived from its editorial design system. All product and collection variants retain the shared Shopify commerce engine unless a section setting explicitly changes presentation. ## Standard templates The standard storefront includes templates for: - homepage; - product; - collection; - collection index; - cart; - search; - page; - contact page; - blog; - article; - 404; - password page; - gift card and account fallbacks. Use standard templates as the functional baseline for a store. They are the best place to validate products, variants, filters, cart, search, navigation, forms, and app blocks before introducing more specialized layouts. ## Merchant-addable sections The standard section library includes: - image banner; - featured collection; - featured product; - collection list; - image with text; - multicolumn; - featured blog; - newsletter; - rich text; - app block wrapper. Sections are configured and ordered through Shopify's theme editor. Keep critical commerce behavior in product, collection, cart, and search sections rather than rebuilding it inside decorative homepage sections. ## Homepage variants Kingsbell includes: ```text index.editorial.json index.archive.json index.private.json index.commission.json ``` Assignable page equivalents are available for the same design directions. ### Editorial Use the editorial direction for campaign-led storytelling, product launches, seasonal narratives, and image-driven merchandising. Typical sections include editorial hero, lookbook grid, numbered story, featured products, and journal content. ### Archive Use the archive direction for catalogues, editions, chronology, collections, and an index-like browsing experience. Typical sections include archive index, structured grids, restrained labels, and collection-led navigation. ### Commission Use the commission direction for bespoke products, made-to-order work, consultations, services, and enquiry-led purchasing. The product form and Shopify checkout entry remain available where the product is directly purchasable. Content should make lead times, scope, options, and next actions explicit. ### Private Use the private direction for invitation-led or member-facing presentation. The theme can conditionally render content based on sign-in, customer tags, or B2B context. Private templates are not a security boundary. Product publication, API access, cart, files, and checkout require Shopify-native or companion-application enforcement. ## Product variants Kingsbell includes: ```text product.editorial.json product.archive.json product.commission.json product.private.json ``` These templates retain configurable support for: - product media; - options and variants; - product forms; - Ajax cart behavior; - inventory and SKU; - pickup availability; - accordions; - app blocks; - related products. The visual arrangement changes, but the product data and form contract remain shared. ## Collection variants Kingsbell includes: ```text collection.editorial.json collection.archive.json collection.private.json ``` These templates retain: - product cards; - pricing and availability; - native filtering; - sorting; - pagination; - Ajax and browser-history behavior. Use Shopify's template assignment controls to apply a variant to a particular collection. Do not duplicate a collection merely to obtain a different layout. ## Variant sections The alternate-template system includes: - editorial hero; - lookbook grid; - archive index; - numbered story; - invitation banner; - variant product engine; - variant collection engine; - scoped variant stylesheet loader. The scoped stylesheet loader prevents alternate-template styling from becoming the global default. Keep new variant styles scoped to a template or section root. ## Assigning templates In Shopify Admin: 1. open the product, collection, page, blog, or article; 2. locate the theme template selector; 3. choose the required Kingsbell template; 4. save the resource; 5. open the theme editor using that resource as the preview context; 6. configure and order its sections; 7. test the resulting page in a storefront preview. Template availability can depend on the currently published theme or on templates present in the theme being customized. ## Creating a custom composition Prefer creating a new JSON template when one product, collection, page, or article needs a distinct composition. A safe workflow is: 1. duplicate the closest existing JSON template; 2. give the new template a descriptive suffix; 3. reuse existing sections; 4. change section defaults and ordering; 5. validate the template JSON; 6. open and save it in the theme editor; 7. test all commerce and accessibility states. Avoid copying a section solely to change its default settings. Template JSON can usually provide a different composition without creating another runtime component. ## Section defaults and optional content JSON template defaults should create a coherent page without requiring every optional field. When a section depends on merchant-provided media, products, collections, articles, or metaobjects: - provide an intentional placeholder in the theme editor where appropriate; - avoid rendering empty wrappers on the live storefront; - disable placeholder-dependent optional sections by default when they would otherwise look broken; - keep headings and navigation meaningful when content is absent. ## Shared behavior across variants A variant must not silently remove core behavior. Retest: - variant selection; - add to cart and dynamic checkout; - app blocks; - pickup availability; - filters, sorting, and pagination; - predictive search and cart synchronization; - customer-account links; - reduced motion and keyboard access. Visual variation is not permission to fork the commerce engine. ## Choosing the right direction Use the smallest amount of specialization that serves the store: - choose **standard** for general-purpose commerce; - choose **editorial** when narrative and campaigns lead discovery; - choose **archive** when taxonomy, editions, or chronology lead discovery; - choose **commission** when purchasing requires explanation, selection, or consultation; - choose **private** only when the store also has an explicit authorization and catalog-enforcement plan. ---