Custom app development
Most of what people ask me to build, I talk them out of.
Pipedrive, plus configuration and automation, covers almost everything a growing business needs. Custom software is what is left when that runs out of road: a step that does not exist anywhere in Pipedrive's data model, a report no report builder can produce, a connection to a system with no integration path. That is a short list. When you land on it, here is what building for you looks like.
Evidence
What we have actually built.
We write software ourselves, not only configuration. Three examples, described generically because the work belongs to the people who paid for it.
- An automation engine. A substantial piece of software that drives Pipedrive's API to read, document and deploy workflow automations. It is the tool behind our automation service (see Pipedrive automation) and we operate it on your behalf. You do not install it or maintain it.
- Client-specific tooling. Scripts that build a fully populated demonstration account, so a team can watch their own process running before committing to it. Tools that export an account's configuration into a spreadsheet a non-technical owner can review.
- A public web calculator suite. For a related business in the Canadian mortgage industry, a set of financial calculators with lead capture, built as software that business owns outright rather than a rented third-party widget. We built it because the rented one lapsed and took the leads with it.
Ownership
What you own when it is finished.
This is the strongest reason to build rather than rent. When we are done, the code is yours. The hosting account, the domain, the API keys: yours. Nothing sits on a subscription that lapses and takes the work with it. Nothing depends on a plugin marketplace choosing to keep supporting it. If you stop paying us, the software keeps running exactly as it did the day before, because there is nothing left to pay for.
The fair question
What happens if I am unavailable.
Custom software should not depend on any one person, including me. That is a reasonable thing to weigh before commissioning custom work, so I answer it with artifacts rather than reassurance.
- Documentation written as I go. Not a wiki that rots: a plain description of what the software does and how, handed over with the code.
- Standard tools, not private frameworks. Nothing I build depends on a framework only I understand. Another developer can open the codebase and recognise it.
- Nothing proprietary or locked. No licence key only I can issue. No account only I can reach.
- Work scoped small enough to hand over. I do not build monoliths. Each piece is small enough that a competent developer can pick it up without a briefing from me.
If I disappeared tomorrow, someone else could open what I built and carry on. That is the test I hold the work to.
Honest limits
When I will tell you not to do this.
If a Pipedrive automation, a native integration or a Make.com scenario solves your problem, I will say so and point you there instead (see integrations). Custom software costs more to build and more to keep running than configuration does, and it is the wrong answer whenever configuration still has room to give. I would rather turn down a build than sell you one you did not need.
Next step
Find out which one you need.
Bring me the problem before deciding it needs custom software. Most of the time it does not. When it does, you will know exactly what you are getting and what you own at the end. A 30-minute call costs nothing.