What this category covers and when it makes sense
Every application we build gets baseline protection: access control, encrypted transport, up-to-date dependencies. This category is about something else — software where security is the product itself. A bug in an online shop usually means downtime. A bug in a password manager or an encryption module means leaking the very data your customers trusted you to protect. That is why we run these projects differently: with a threat model, cryptographic decisions written down before the first line of code, and a plan for independent review.
When building your own security product is justified
- You are building a product to sell — as a software vendor, a managed service provider (MSP) or a security company.
- Off-the-shelf tools fail your deployment constraints: air-gapped networks, customer-hosted installation only, or a specific data location.
- The security function has to live inside your platform, for example encrypting documents with keys that even the service operator cannot access.
- You need an integration layer: inventory, prioritisation and reporting built on top of existing engines.
If an existing commercial or open-source tool already solves the problem, we will say so. A licence is then cheaper and safer than maintaining your own cryptographic code for years.
Three product types in this category
Password managers
A credential vault with client-side encryption, sync across devices, team sharing and autofill in the browser and on phones. The hardest decisions concern account recovery and the device lifecycle, not the interface.
Encryption software
Encryption of files, database fields, backups or attachments — delivered as an application, a library or a key-management service. The starting point is a clear answer to who may see the data in plaintext and who holds the keys.
Vulnerability scanners
Defensive tools for regular checks of assets the customer is authorised to test: networks, web applications, dependencies or container images. The value lies in inventory, evidence, false-positive control and the remediation workflow, not in detection alone.
How to pick the right starting point
Start with the asset you need to protect and the adversary you are protecting it from.
- Credentials — passwords, API keys, access codes shared within a team. Direction: a password manager or a secrets vault.
- A specific data type — documents, customer records or backups that must stay unreadable to unauthorised people, including the cloud administrator. Direction: encryption with a clearly defined key owner.
- Unknown weaknesses in assets you own or manage for clients. Direction: a vulnerability scanner with a target-authorisation model.
These products often overlap. A scanner running authenticated checks has to store credentials for the systems it tests, and a password manager relies on the same primitives as encryption software. In that case we pick one lead product with one business owner and describe the other capabilities in the specification as modules with their own acceptance criteria. That keeps the first release from turning into three parallel projects.
How we run a security product project
- Threat model before code. We record protected assets, trust boundaries, attack and misuse scenarios, and what the product deliberately does not defend against. The document becomes part of the specification and the basis for tests.
- Established primitives, no home-made cryptography. We use mature libraries (for example libsodium or Tink) and platform APIs (WebCrypto, Android Keystore, Keychain, Windows CNG). Algorithms and data formats are versioned so they can be replaced later.
- Verification against standards. OWASP ASVS serves as the reference for web applications and backends, and OWASP MASVS for mobile apps, to the depth agreed in the specification.
- Supply-chain control. Pinned dependency versions, automated checks for known vulnerabilities, an SBOM in CycloneDX or SPDX format, signed releases and restricted access to signing keys.
- Vulnerability handling from day one. A disclosure policy (for example a security.txt file), an update channel, severity rating and a patch schedule.
- Room for independent review. We prepare design documentation for a specialist firm you select and then implement the fixes from its report.
Service boundaries and regulation
We build software. We do not perform security audits, penetration tests, SOC monitoring or incident response, and we do not issue certifications. If the product needs FIPS 140-3 validation, a Common Criteria evaluation, or has to support your ISO/IEC 27001 certification, we design it to make that process easier — but an accredited body runs it.
Depending on your market and customers, the scope may need to address:
- GDPR — data minimisation, encryption as a technical measure, the ability to erase data permanently;
- the Cyber Resilience Act — EU requirements for manufacturers of products with digital elements, including vulnerability handling and security updates throughout the support period;
- NIS2 — obligations of your customers that turn into requirements for their software suppliers;
- export controls — rules on distributing cryptographic products outside the EU.
We help translate these requirements into features and technical documentation. Legal classification of the product and the assessment of obligations belong with your legal adviser.
Budget, options and third-party costs
Security products are priced against the high-complexity software anchor: from $12,000 excluding VAT for a focused first release. We usually begin with discovery and a technical specification ($490–$1,500), which ends with a threat model, an architecture and a proposal in three options: Essential, Recommended and Scale.
Engagements run as fixed scope after discovery, time and materials, or dedicated capacity (from $6,500 per month). Proposals are issued in USD, EUR or GBP. Excluded from the price are, among others, independent cryptographic review or audit, code-signing certificates, app and extension store accounts, KMS services or HSM hardware, commercial vulnerability feeds and cloud consumption.
Maintenance starts from $249 per month and in this category it is not optional: a security tool that stops receiving updates quickly becomes a risk itself. All anchors are listed on the software development pricing page.
Cybersecurity Software Development
Frequently asked questions
Can you run a security audit or penetration test of our application?
No. Our service is designing and building security products. We can prepare documentation for an independent audit firm, join the walkthrough of its findings and implement the fixes from its report.
Can a password manager and a vulnerability scanner be one product?
Yes, it is a common combination — for example a scanner that keeps credentials for authenticated scans in an encrypted vault. We then define a lead product and describe the other as a module with its own threat model and acceptance criteria.
Is $12,000 a fixed price?
It is an indicative anchor for a focused first release. The final price follows a written technical specification and comes in three scope options. Development starts only after scope and price are agreed in writing.
Can you continue an existing security tool codebase?
Yes, after a code assessment during discovery. We review the cryptographic libraries, dependencies, key storage and release process. The result is a risk list and a recommendation: continue, refactor selected modules or replace them.
Will the product comply with GDPR and the Cyber Resilience Act?
We design features and processes that support those requirements: data minimisation, encryption, vulnerability handling and updates. Compliance assessment and product classification belong to your legal adviser, to whom we supply the technical documentation.
Which languages and markets do you work with?
We are based in Wrocław and work with clients in Poland, the European Union, the United Kingdom, the United States and Canada. We communicate in English, Polish, Russian and Ukrainian and prepare project documentation in the agreed language.