Augmenting, not replacing
Most engagements here add capacity to an existing team. That means your repository, your conventions, your CI and your review process, so what we ship is indistinguishable from what your engineers write.
San Francisco
Software development in San Francisco built for your team to keep.
The Bay Area brief is rarely build us something and go away. It is usually extend what we have, in our conventions, so our engineers can own it after.
Overview
What Bay Area software work looks like
Custom software for Bay Area companies is shaped by the fact that most clients already have engineers. The work is usually augmenting capacity, building a service that fits an existing architecture, or taking a product from prototype to something maintainable. Code quality and documentation matter more here because someone technical will inherit it.
Prototype to production
A common brief: something works, was built fast, and now needs to be maintainable, tested and able to handle real traffic. That is a different job from greenfield and needs scoping as one.
SaaS as a product, not a project
A SaaS platform needs iteration, support and a roadmap rather than a launch. We will be direct about whether you are resourced for that, because a product without ongoing investment stalls regardless of how well it was built.
Integration with a real stack
Bay Area companies run a lot of systems. Integration work is usually the majority of the effort, and the engineering that matters is failure handling, retries and rate limits rather than the connection itself.
Code someone else will read
Your engineers will review what we write. Documented architecture decisions, tests, and conventions that match yours. Undocumented work fails the first code review and costs more to fix than to have done properly.
Yours from day one
Code in your repository, infrastructure in your accounts, documentation as a deliverable. Not handed over at the end, owned throughout.
Pricing
What drives the cost
| Factor | Why it moves the number | What to ask |
|---|---|---|
| How many rules | Business logic is the bulk of the work | Are the rules written down? |
| Existing architecture | Fitting an established system takes longer | How will you learn our stack? |
| Integrations | Each one is a project of its own | What happens when one fails? |
| Test coverage expected | Real coverage is real time | What level of testing is included? |
| Working in your process | Your CI, review and conventions | How do you integrate with our team? |
| Who maintains it | Someone does, or it rots | Who owns this in month twelve? |
We scope after a discovery engagement that produces a written specification you keep. Pricing custom software before the rules are documented produces a number that is wrong for both sides.
Detail
What to ask before you hire
| Ask them | A good answer sounds like | Walk away if |
|---|---|---|
| Who owns the code and accounts? | You do, in your own accounts, from day one | It ships under their account |
| Can I open three things you built? | Live links you can use today | Screenshots and mockups |
| What is explicitly not included? | A written list with change pricing | Everything is included |
| What happens after launch? | A named arrangement and response time | Not discussed until it breaks |
The account ownership question is the one people forget, and it is the hardest to fix afterwards.
Limits
When we would tell you not to build
A platform already does it
Standard CRM, billing, analytics, support. Custom here means rebuilding solved problems and inheriting the maintenance.
The rules are still being argued
Building software freezes an internal argument into code. Settle it on paper first; it is dramatically cheaper.
There is no one to maintain it
Custom software needs dependency updates and security patches. Without an owner it ages faster and more dangerously than a platform, because nobody is patching your specific application.
FAQ
Common questions
Do you work inside our repository and conventions?
Yes, and that is the normal arrangement for Bay Area engagements. Your repo, your CI, your review process and your conventions, so what we ship is maintainable by your engineers rather than a black box.
Can you take a prototype to production?
Yes, and it is a distinct job from greenfield: making something maintainable, tested and able to handle real traffic. We audit what exists first and tell you honestly whether hardening or rebuilding is better value.
Do you build SaaS products?
Yes, and it is a longer commitment than a project. A product needs iteration, support and a roadmap. We will be direct about whether you are resourced for that before starting.
How do you handle testing?
Test coverage is scoped explicitly rather than assumed, because real coverage is real time and it is a common source of disagreement. Tell us what level your team expects and we will price to it.
Will we own the code?
From day one. Code lives in your repository and infrastructure in your accounts rather than being transferred at the end. Documentation is a deliverable, not a favour.
Do you have an office in San Francisco?
No. We work remotely on overlapping Pacific hours and would rather state that than imply otherwise. Not carrying Bay Area overheads is a real part of the cost difference in a multi-month engagement.
When would you tell us not to build custom?
When a platform already does it, when the business rules are still being argued internally, or when there is nobody to maintain it afterwards. All three are common and all three are cheaper to hear before the build.
Next step
Tell us what you need.
Send us what you are trying to fix and we will tell you what it takes, what it costs, and whether we are the right people for it. If we are not, we will say so.