03Service line
Software and product development services with security built into delivery
Onion Infosec designs, builds and modernizes software: web and mobile applications, SaaS platforms, enterprise systems and the APIs behind them. Threat modeling, secure coding standards, pipeline security and pre-release testing are part of delivery, carried out by the same company.
- Line
- 03 of 07 · Software & Product Development
- Shape
- Discover → Build → Modernize → Verify → Deliver
- Delivery
- Project, retainer or managed service
01Context
What the development service line covers
The line covers the full product lifecycle. Discovery and UX design define what to build. Engineering teams build frontends, backends, APIs, data stores and integrations. QA and DevOps make releases repeatable. Modernization work moves legacy systems onto architectures that can be maintained and scaled.
Work is delivered as a project, a dedicated team or a review. Code lives in your repositories from the first commit, with documentation and pipelines that let another team take over. Security work sits in the same backlog as features and is planned in each iteration.
- Delivery speed depends on engineering discipline
- Automated tests, continuous integration and small releases keep change cheap. Without them, each release gets slower and riskier as the codebase grows.
- Legacy systems limit what the business can change
- Applications that cannot be deployed safely, scaled or integrated hold back every project that depends on them. Modernization in planned increments reduces that constraint without a full rewrite.
- Security defects are cheapest to fix at design time
- A flaw found in a threat model costs a design conversation. The same flaw found in production costs an incident and a hotfix. Building the checks into delivery moves discovery earlier.
Architecture
Security and the platform run through delivery.
The stages are familiar. What matters is what runs underneath them, and that none of it waits for the end.
Software delivery in eight stages: Discover, Design, Engineer, Test, Secure, Deploy, Operate, Improve. Three lanes run beneath them. Product: Discovery and UI/UX design during Discover and Design; QA and test automation during Test and Secure; Application support during Operate and Improve. Security: Threat modeling during Design; SAST, SCA and secrets scanning during Engineer and Test; Penetration testing during Secure; Artifact integrity during Deploy; Monitoring and response during Operate and Improve. Platform: Architecture and cloud design during Discover and Design; CI/CD pipeline and infrastructure as code during Engineer and Test and Secure and Deploy; Cloud operations and observability during Operate and Improve.
- Discovery and UI/UX design
- Architecture and cloud design
- Discovery and UI/UX design
- Threat modeling
- Architecture and cloud design
- SAST, SCA and secrets scanning
- CI/CD pipeline and infrastructure as code
- QA and test automation
- SAST, SCA and secrets scanning
- CI/CD pipeline and infrastructure as code
- QA and test automation
- Penetration testing
- CI/CD pipeline and infrastructure as code
- Artifact integrity
- CI/CD pipeline and infrastructure as code
- Application support
- Monitoring and response
- Cloud operations and observability
- Application support
- Monitoring and response
- Cloud operations and observability
02Approach
How we build software
Projects start with a short discovery phase that fixes scope, architecture and the first release plan. Build then runs in short iterations with a working demo at the end of each. Backlog, code, pipelines and environments are visible to your team throughout.
Quality and security checks run in the pipeline on every change: unit and integration tests, static analysis, dependency and secrets scanning, and infrastructure policy checks. Architecture decisions are written down as short decision records, so the reasons survive team changes.
01
Your code, your repositories
Source, infrastructure code and documentation are committed to repositories you own. Nothing depends on Onion-hosted tooling to build or run.
02
Small releases, automated checks
Trunk-based development, feature flags and automated tests keep each release small enough to review and easy to roll back.
03
Threat model with the design
New features that cross trust boundaries, handle authentication or touch sensitive data get a threat model during design. Mitigations become backlog items with owners.
04
Built to be handed over
Runbooks, architecture records and onboarding notes are written during the build, so an internal team or our managed services team can operate the system.
03Capabilities
How software development work is organized.
Discover
Establish the problem, the users and the shape of the product.
Build
Engineer applications, platforms and the APIs behind them.
Modernize
Bring existing systems forward without stopping the business.
Verify
Test function, performance and security before release.
Deliver
Ship through pipelines that are fast, repeatable and secured.
Product discovery and UI/UX design
Work that settles what to build and how it should behave before engineering cost is committed. Outputs are concrete: scope, flows, prototypes and an architecture direction.
- Product discoveryStakeholder interviews, user research and process mapping that turn an idea or problem statement into a defined scope, user stories and a release plan.
- Technical feasibility studyShort investigation of the hardest technical questions, such as integrations, data volumes or performance limits. Ends with a recommended architecture and a list of known risks.
- UX research and information architectureUser flows, navigation structure and content hierarchy, validated with representative users before visual design begins.
- UI design and prototypingWireframes, high-fidelity screens and clickable prototypes in Figma, tested with users and handed to engineering with specifications.
- Design systemsA reusable component library with design tokens, accessibility rules and coded components, so that new screens stay consistent and are faster to build.
- Accessibility reviewEvaluation of designs and built interfaces against WCAG 2.2. Issues are listed by severity with fixes described for designers and developers.
Web and mobile applications
Customer-facing and internal applications for browser and device. Frontend engineering is treated as a discipline of its own, with attention to performance, accessibility and state management.
- Web application developmentResponsive web applications built with React, Next.js, Angular or Vue, using server-side rendering where search visibility or first-load speed requires it.
- Frontend engineeringComponent architecture, state management, performance budgets and automated UI tests for complex single-page and multi-page applications.
- Native mobile developmentiOS and Android applications in Swift and Kotlin, chosen where device capabilities, performance or platform conventions call for native code.
- Cross-platform mobile developmentShared-codebase applications in React Native or Flutter, with native modules where needed and release pipelines for both app stores.
- Progressive web appsInstallable web applications with offline support, background sync and push notifications, for cases where an app store release is not required.
- Portals and dashboardsCustomer, supplier and staff portals with role-based access, reporting views and integration with your identity provider.
SaaS and enterprise software
Multi-tenant products and internal business systems. The focus is on the parts that are expensive to change later: tenancy, identity, data model, billing and integration.
- SaaS product engineeringDesign and build of multi-tenant SaaS platforms, including tenant isolation, onboarding, subscription and billing integration, and admin tooling.
- MVP developmentA first releasable version scoped to the smallest feature set that tests the product with real users, built on an architecture that does not need to be discarded.
- Enterprise application developmentCustom line-of-business systems such as workflow, case management and operations platforms, integrated with ERP, CRM and identity systems.
- Identity and access for applicationsSingle sign-on, multi-factor authentication, role and attribute-based authorization, and audit logging built on OAuth 2.0, OpenID Connect and SAML.
- Data and reporting layersData models, pipelines and reporting interfaces that give product and operations teams accurate figures without querying production databases directly.
- Dedicated product teamsA standing cross-functional team of engineers, QA and design that works to your roadmap and ceremonies under your product owner.
API, backend and full-stack engineering
The services, data stores and interfaces that applications depend on. Designed for clear contracts, predictable performance and safe change.
- API design and developmentREST, GraphQL and gRPC interfaces designed contract-first with OpenAPI or schema definitions, a versioning policy and consumer documentation.
- Backend and microservices engineeringServices in Node.js, Python, Java, .NET or Go, structured as a modular monolith or as microservices according to team size and scaling needs.
- Full-stack deliveryOne team responsible for frontend, backend, data and deployment of a product, which removes handoffs on small and mid-sized builds.
- Systems integrationIntegration with third-party and internal systems through APIs, message queues and event streams, with retry, idempotency and monitoring designed in.
- Database design and performanceSchema design, indexing, query tuning and migration strategy for relational and document databases, with backup and recovery tested.
- API security engineeringAuthentication, authorization, input validation, rate limiting and logging implemented against the OWASP API Security Top 10.
Application modernization
Planned, incremental change to systems that still run the business. Each step leaves the application working and deployable.
- Legacy application assessmentReview of code, architecture, dependencies, data and operations that classifies each application for retain, rehost, replatform, refactor or replace, with effort and risk estimates.
- Re-architecture and refactoringIncremental extraction of modules and services using the strangler pattern. Tests are added around existing behavior before it is changed.
- Framework and runtime upgradesMigration from unsupported language versions, frameworks and libraries to supported releases, including dependency cleanup and regression testing.
- Cloud migration of applicationsContainerization and replatforming of applications onto managed cloud services, coordinated with our cloud engineering team.
- Database migrationMovement of schemas and data between engines or versions, with reconciliation checks, a cutover rehearsal and a rollback plan.
- Code and architecture reviewIndependent review of maintainability, test coverage, security, performance and operability, reported with prioritized recommendations.
QA and testing
Testing that is planned with the build instead of added at the end. Automated suites run in the pipeline, and manual effort goes to exploratory and usability testing.
- Test strategy and planningA documented approach that sets test levels, environments, data, tooling and release criteria for the product.
- Test automationUnit, API and end-to-end suites using tools such as Playwright, Cypress and Appium, integrated into CI with reporting on coverage and flaky tests.
- Functional and regression testingManual and automated verification of features against acceptance criteria, with a regression pack maintained for each release.
- Performance and load testingLoad, stress and soak tests with k6, JMeter or Gatling that establish capacity limits and find bottlenecks before production traffic does.
- Mobile and cross-browser testingVerification across the device, operating system and browser combinations that match your user base, on real devices and cloud device farms.
- Pre-release security testingWeb, API and mobile penetration testing of release candidates by our offensive security team, with findings returned to the same backlog.
DevOps, DevSecOps and CI/CD
Delivery pipelines and the controls inside them. The build system holds production credentials and deploys trusted artifacts, so it is engineered and secured as production infrastructure.
- CI/CD pipeline engineeringBuild, test and deployment pipelines on GitHub Actions, GitLab CI, Azure DevOps or Jenkins, with environment promotion, approvals and rollback.
- Infrastructure as code and environmentsTerraform, Bicep or CloudFormation for repeatable development, test and production environments, including short-lived environments for pull requests.
- DevSecOps implementationSAST, SCA, secrets detection, container scanning and infrastructure scanning wired into pull requests and tuned until developers trust the results.
- Pipeline and supply chain securityRunner isolation, secrets management, branch protection, SBOM generation, artifact signing and provenance aligned with SLSA principles.
- Application security programA secure development lifecycle sized to your engineering organization: standards, threat modeling practice, tooling, security champions and metrics.
- Release and observability engineeringBlue-green and canary releases, feature flags, structured logging, metrics and tracing, with alerts tied to service-level objectives.
04Process
How a software development engagement runs.
Discover
Clarify users, goals, constraints and integrations. Agree scope, architecture direction and the first release.
Design
Produce UX flows, interface designs, the data model, API contracts and the threat model. Record key architecture decisions.
Build
Develop in short iterations with code review, automated tests and security checks on every pull request. Demo working software at the end of each iteration.
Verify
Run functional, performance and accessibility testing, then a penetration test of the release candidate. Fix findings and confirm the fixes before launch.
Release
Deploy through the pipeline with a staged rollout, monitoring and a rollback path.
Operate and improve
Hand over with runbooks and training, or continue with a dedicated team or managed support. Production data and user feedback go into the backlog.
What you receive
- Discovery report with scope, user flows, architecture and release plan
- UX and UI designs, prototype and design system
- Source code, infrastructure as code and pipelines in your repositories
- Automated test suites with coverage and performance baselines
- Threat models, security test reports and remediation records
- Architecture decision records, API documentation and runbooks
- Software bill of materials for each release
- Handover and onboarding materials for the receiving team
05Technical depth
Typical software development engagements, technology and methods.
Discovery sprint
A short, fixed-scope engagement that produces validated scope, user flows, a recommended architecture, a release plan and a budget range for the build.
MVP build
A fixed-scope project delivered in iterations, from design to a first production release with pipelines, monitoring and documentation in place.
Dedicated product team
A cross-functional team on a monthly retainer that works to your roadmap. Team composition changes by agreement as priorities shift.
Modernization program
A multi-phase program that begins with a portfolio assessment and then modernizes applications in planned waves, each with its own cutover and rollback plan.
Code and architecture review
A short independent review of an existing codebase or design. Suitable before an acquisition, a major investment or a change of development supplier.
DevSecOps implementation
A project that threat-models the delivery pipeline, hardens it and integrates security testing, followed by enablement sessions for developers.
Technology areas
Frontend
Mobile
Backend
Data and messaging
Delivery and platforms
Quality and security tooling
Technologies are named to describe the work. Naming a product does not indicate a commercial partnership.
Frameworks and methods
OWASP ASVS
Source of security requirements for web applications and APIs, selected by verification level during design.
OWASP Top 10 and API Security Top 10
Reference for developer training, code review checklists and security test coverage.
OWASP SAMM
Maturity model used to assess a secure development practice and plan improvements.
NIST SSDF (SP 800-218)
Practice catalog for secure software development, used to structure the SDLC and to answer customer security questionnaires.
SLSA
Levels and requirements for build integrity and artifact provenance, applied to pipeline design.
STRIDE threat modeling
Method for finding design-level threats across trust boundaries in feature and architecture reviews.
WCAG 2.2
Accessibility criteria applied in design review and interface testing.
DORA software delivery metrics
Deployment frequency, lead time, change failure rate and time to restore, used to track delivery performance.
06Across lines
Security work is done by the same company that writes the code.
Threat modeling happens during design. Secure coding standards and review checklists apply to every pull request. The pipeline runs static analysis, dependency, secrets and infrastructure checks, and is itself hardened. Before release, our offensive security team tests the application and returns findings to the same backlog. One company is accountable for building the software and for testing it.
07Questions
Software & Product Development: questions we are asked
You do. Ownership terms are set in the contract, and in practice code is committed to repositories you control from the start of the project, together with infrastructure code, pipelines and documentation.
Yes. We can join an existing team, take over a codebase or run a separate workstream. Work on an inherited codebase starts with a code and architecture review, so that estimates rest on what is there.
The stack is chosen per project based on the product, your existing systems and the skills of the team that will maintain it. The technology section lists what we work with most often. A widely supported stack your team can hire for is usually the right choice.
Tuned pipeline checks find issues in pull requests, where they take minutes to fix. Threat modeling adds a short design session for features that need it. The slower alternative is a security gate before release followed by emergency patching.
Testing is done by the offensive security team, which is separate from the delivery team and reports its findings in full. Where a third-party test is required for assurance or compliance, we support it with documentation and fix what it finds.