This document describes how Cobenian designs, writes, checks and delivers software. It applies to every project, paid or free, and is referenced in our agreements.
Who does the work
The work is done by Cobenian, its employees and contractors. Occasionally a specialist partner helps with a specialized component, always under Cobenian's direction and bound by Cobenian's confidentiality obligations.
Cobenian FREE Build projects are done by Bryan Weber, Cobenian's founder, who has more than 25 years of professional software experience. He writes the specification with you, builds the project and hands it over himself.
Process
We write down what the software must do before we write any code, and every later step is checked against that document.
- Specification. We write a specification with you in plain, testable statements of what the software must, should and may do. You approve it before work starts.
- Plan. We turn the specification into mockups of the key screens, which you review, and an implementation plan, broken into phases, which we check against our quality criteria.
- Build. We write the code from the plan, in small changes, and show you working software as we go so we can iterate on your feedback.
- Test. We write automated tests from the specification, so each requirement has a test that proves it.
- Triage. Anything that fails or surprises us is traced back to the specification, the plan or the code, and fixed at the source.
Technology
We use the right tool for the job. For web applications our default is the stack below, because tools we know deeply keep a short build fast and low-risk. When a project calls for something else, such as Python, Go or Rust, we use it and say why in the specification.
| Layer | What we use | Why |
|---|---|---|
| Language and runtime | Elixir on the Erlang VM | Reliable under load, and recovers from faults by design |
| Web framework | Phoenix and LiveView | Interactive pages with very little JavaScript to maintain |
| Interface | Tailwind CSS and daisyUI | Consistent screens with light and dark modes |
| Database | PostgreSQL | Mature, well understood, and easy to host anywhere |
| Background work | Oban | Scheduled and retried jobs stored in the same database |
We keep page-level code thin and put behavior in small, reusable components. We prefer the simplest design that meets the specification.
Professional standards
Every build meets the standards you would expect from professional software:
- Accessibility: we target WCAG 2.2 level AA.
- Security: the practices listed under Security below.
- Tests: automated tests derived from the specification.
- Documentation: a handover document covering how the software works and how to run it.
Quality checks
Every change passes the same checks before it is merged:
- The code is formatted with the standard formatter and compiles without warnings.
- The automated tests pass.
- Existing helpers and components are reused before new ones are written.
All code lives in a Git repository from the first day, and you receive the full repository at handover.
AI development tools and your data
We use AI development tools, including Anthropic’s Claude, to write specifications, code and tests, so some of your project information will pass through them. By taking part, you accept that this information is processed under those providers’ terms, including Anthropic’s privacy policy.
We work from sample or anonymized data wherever real data isn’t needed, and we tell you before real data is used.
Security
Security is designed in from the specification, and these practices apply to every build:
- Access: every page and action checks who the user is and what they are allowed to do. Nothing is public unless the specification says so.
- Passwords and sessions: passwords are stored only as salted hashes, using the framework's standard authentication. Sessions are signed and expire.
- Input and output: database queries are parameterized, output is escaped by default, and forms carry protection against cross-site request forgery.
- Secrets: API keys, passwords and tokens are never stored in the code repository. They live in the hosting platform's secret store.
- Transport: all traffic uses HTTPS.
- Dependencies: we use a small number of well-maintained libraries, check them against known vulnerabilities before handover, and list them in the handover document.
- Least privilege: database users and cloud roles get only the permissions the application needs.
- Security review: we review our own code for security before handover.
- Our access: we work in your accounts with our own named logins, and our access is removed at handover unless you have a maintenance plan.
Deployment
Software that runs on your own machines or devices is installed there. For web and cloud software, we can deploy to a cloud account that you own, so you control it and can change providers or developers at any time. If you prefer, we can host it for you for a monthly fee. Either way, we design the software to keep its ongoing operating costs low.
- Our default hosts are Fly.io and Amazon Web Services. We can also deploy to Microsoft Azure or Google Cloud when you already use one of them.
- The application is packaged as a container, so it runs the same way on any of these.
- Deployment is a documented, repeatable command or pipeline, not a manual procedure.
- Automated database backups are switched on before handover, and we confirm that a restore works.
- The handover document explains how to deploy, roll back, read the logs and rotate secrets.
What a two-week build does not include
A two-week build delivers working, tested software for the agreed scope. It does not include the following unless the scope of work says so:
- Ongoing support, monitoring or updates after handover. These are available under the optional maintenance and security plan.
- An independent, third-party security audit or penetration test. We do review our own code for security, as described above.
- Compliance certification, such as HIPAA, PCI DSS or SOC 2.
- Load testing beyond the usage described in the specification.
- Migration of historical data beyond what the scope of work lists.
- Native mobile apps.
- Training beyond one walkthrough session at handover.