Custom .NET development
Eighteen years of building and rescuing .NET systems - line-of-business applications, integrations, and the software that runs a business from the inside.
Most of our work has no CMS in it at all
AHD is known for DXP work, but the larger part of what the team does is ordinary, serious .NET engineering: internal systems, integration layers, data processing, and applications that have to keep running while they are being changed.
It is less photogenic than a website launch and it is where most of the value sits. A CMS replatform happens once every five years. The system that schedules the work, reserves the stock and chases the unpaid balances runs every working day.
Custom CRM and sales systems
A general-purpose CRM models three things well: a company, a contact and a deal. That is enough for a business whose product is undifferentiated and whose sales process is a series of conversations.
It stops being enough the moment the thing you sell has structure of its own. If a sale depends on a specific unit that can be reserved and released, on a stage set by regulation rather than by a salesperson, or on an engineer with the right certification being free on Thursday, a general CRM has no field for it. So it gets rebuilt in custom fields - and the moment that happens, nobody trusts the pipeline figure, because the pipeline figure is now assembled from free text.
A custom CRM is worth building when the domain has that structure and the pipeline number has to be real. It is not worth building when a configured commercial CRM would do the job, which is more often than software suppliers tend to admit.
What changes by sector
The same architecture, a different domain model. These are the questions that decide the build.
Property and development
Units inside buildings, each individually sellable. Reservations that expire and return stock to the market. Construction and certification stages that decide what can legally be sold and when it can complete - in Bulgaria, Акт 14 and Акт 16.
Professional services
Engagements rather than deals, retainers that renew, and utilisation as the number that actually matters. Time recorded against work has to reconcile to what was invoiced, or the reporting is decorative.
Field service
Jobs with locations, engineers with skills, certifications and availability, parts that have to be in the van. Scheduling is the hard part and it is what a general CRM handles worst.
Distribution and wholesale
Accounts with negotiated price lists and credit limits, quotes that become orders, and stock that is promised to several customers at once until somebody decides who gets it.
Membership and education
Cohorts and enrolments rather than one-off sales, renewals that need chasing before they lapse, and eligibility rules that change what a given person can buy.
Regulated sales of any kind
Where a stage is set by a certificate, an inspection or an approval rather than by a salesperson's optimism. Modelling that properly is the difference between a forecast and a wish.
What a custom CRM usually includes
Not every system needs all of it. Most need more of it than they expect.
Domain inventory
Whatever it is you actually sell, modelled as a first-class thing with its own states and its own rules - not as a custom field hanging off an opportunity.
Pipeline and forecasting
Leads, opportunities and closed business, with the value computed from real records at real prices rather than typed into a box.
Reservations and holds
Where the domain needs it: a hold with its own lifecycle and expiry, which changes what is available to sell while it is live.
People and permissions
Role-based access that reflects genuinely different jobs. A consultant sees their own book, a manager sees the team, an administrator sees everything.
Scheduling and calendars
Shared calendars for appointments, viewings or site visits, with the availability rules that make the scheduling trustworthy.
Tasks and reminders
Follow-ups attached to the record rather than to a person, so nothing is lost when somebody is on holiday or leaves.
Reporting and exports
The handful of figures the business is actually run on, compared against the previous period, exportable to CSV, Excel and PDF without a developer.
Configurable vocabulary
Statuses, sources and categories held as data, not code, so the business changes its own terminology without raising a ticket.
Integrations
Accounting, marketing, telephony, the public website. Including what happens when one of them is unavailable, which is the part that normally gets skipped.
Design decisions worth making early
The choices that make it a system rather than a database with screens on top.
| Decision | The choice | Why it matters |
|---|---|---|
| Domain model | Model what you sell as its own entity, with its own states | Forcing it into custom fields is what makes the pipeline number untrustworthy. Everything downstream inherits that. |
| Regulatory stages | Track the certificates, inspections or approvals that gate a sale | In regulated sales these, not a sales stage, decide what can be sold and when it can complete. |
| Localisation | Full multilingual support down to data labels and status values | A floor that works in one language and reports in another needs both to be first-class, not one bolted on. |
| Access control | Role-based, reflecting real jobs rather than seniority | Reception, sales and administration are three genuinely different views of the same data. |
| Architecture | Headless where the same data serves more than one surface | Lets one back end serve the internal system, a public listings or catalogue site, and later a mobile client. |
| Configuration over code | Statuses, sources and categories editable in the application | Every business changes its vocabulary. Charging them to deploy a dropdown value is a bad arrangement for both sides. |
| Build vs configure | Decide honestly, in writing, before anything is built | The cheapest custom CRM is the one you did not need. We would rather lose that project than deliver it. |
What else we build
CRM is one shape this work takes. These are the others.
Line-of-business applications
Internal systems that encode how a business actually works - scheduling, tracking, approval, reporting. Usually replacing a spreadsheet that outgrew itself years ago.
Integration layers
Making a CRM, an ERP, a website and a payment provider agree with each other reliably, including the retry, failure and reconciliation behaviour that normally gets skipped.
APIs and services
REST and messaging services built to be consumed by people who are not in the room, and versioned so they can keep being consumed.
Data and reporting
SQL Server work from schema design through query optimisation to the backup and Agent configuration nobody thinks about until it matters.
Modernisation
Taking a .NET Framework application that still earns its keep and finding a route forward that does not require stopping the business to do it.
Rescue work
Inheriting a codebase from a team that has moved on, working out what it really does, and making it safe to change again.
How we work
Three things that describe an engagement more usefully than a methodology name.
We read before we quote
The two-week assessment applies to application work as much as to platform work. A quote written without reading the code is a guess with an invoice attached.
We work alongside your team
Most engagements are joint. Your developers know why the strange decisions were made, and that context is worth more than anything we would rediscover slowly.
We write things down
Handover documentation is part of delivery, not an optional extra at the end. You should be able to replace us without it being a crisis.
Questions about .NET and CRM work
01.When is a custom CRM the right answer?When what you sell is not a company, a contact and a deal. If your sales process turns on inventory that can be reserved and released, on stages set by regulation or construction, on engineers and their availability, or on anything else a general CRM has no field for, you end up rebuilding it in custom fields anyway - slowly, and without the reporting.
When what you sell is not a company, a contact and a deal. If your sales process turns on inventory that can be reserved and released, on stages set by regulation or construction, on engineers and their availability, or on anything else a general CRM has no field for, you end up rebuilding it in custom fields anyway - slowly, and without the reporting.
02.When is it the wrong answer?When a configured Salesforce, HubSpot or Dynamics would genuinely do the job. That is more often than vendors of custom software like to admit, and we will say so. Building software you could have licensed is an expensive way to own a maintenance burden.
When a configured Salesforce, HubSpot or Dynamics would genuinely do the job. That is more often than vendors of custom software like to admit, and we will say so. Building software you could have licensed is an expensive way to own a maintenance burden.
03.Can it integrate with the CRM we already have?Often the better route. A custom layer that models your actual domain, sitting alongside a commercial CRM that keeps the contact and marketing side, gets you the parts each is good at. Whether that is worth the integration cost depends on your situation.
Often the better route. A custom layer that models your actual domain, sitting alongside a commercial CRM that keeps the contact and marketing side, gets you the parts each is good at. Whether that is worth the integration cost depends on your situation.
04.Do you work on existing systems or only new builds?Mostly existing. A large part of what we do is taking on a .NET application somebody else wrote, understanding it properly, and making it safe to change again. Greenfield work is the easier half of the job.
Mostly existing. A large part of what we do is taking on a .NET application somebody else wrote, understanding it properly, and making it safe to change again. Greenfield work is the easier half of the job.
05.Which .NET versions do you work with?Current .NET for anything new. In practice we spend a lot of time on .NET Framework applications that need to keep running while a migration path is worked out, and that migration is often the engagement itself.
Current .NET for anything new. In practice we spend a lot of time on .NET Framework applications that need to keep running while a migration path is worked out, and that migration is often the engagement itself.
06.Can you take over a system with no documentation?Yes. That is a normal starting condition rather than a complication. The first deliverable in that case is usually a written description of what the system actually does, which frequently differs from what everyone believes it does.
Yes. That is a normal starting condition rather than a complication. The first deliverable in that case is usually a written description of what the system actually does, which frequently differs from what everyone believes it does.
07.Can the system work in more than one language?Yes, and properly rather than as a translation layer added afterwards - navigation, data labels, status values and reports all localised. A system used by a sales floor in one language and reported on in another has to be both at once.
Yes, and properly rather than as a translation layer added afterwards - navigation, data labels, status values and reports all localised. A system used by a sales floor in one language and reported on in another has to be both at once.
08.Where is the team based?Sofia, Bulgaria. Central European time, which overlaps a full working day with the rest of Europe and most of the Middle East.
Sofia, Bulgaria. Central European time, which overlaps a full working day with the rest of Europe and most of the Middle East.
Tell us what you are running
Whether it is a system that needs building, one that needs rescuing, or one nobody understands any more - start by telling us what it does.