eDentaa
Book a free consultation

Eight sectors we have delivered in.

Each one below has the problems that keep recurring, the systems we build for it, the stack we typically use, and what a first engagement looks like. Written at sector level on purpose: we do not name clients or describe individual projects.

Expand a sector to read the detail. If yours is not here, say so on a call and we will tell you honestly whether the work is close enough to something we have done.

What comes up repeatedly

  • Practice-management and clinical systems are bought, not built, and they rarely do the one thing a given clinic needs. The vendor roadmap is measured in years.
  • Clinical staff will not use a second application that duplicates data entry. Anything new has to live inside the workflow they already have.
  • Patient data restricts where things can run and who can see them, which rules out a lot of convenient shortcuts.
  • Downtime during clinic hours is not an option, so releases have to be small and reversible.

What we build for it

  • Plugins and add-ins that extend existing clinical software rather than replacing it
  • Desktop tools for clinical or administrative tasks the main system handles badly
  • Document and letter generation from clinical records
  • Reporting for clinical audit and internal review
  • Interfaces between clinical systems and billing, scheduling or reporting tools

Typical stack

.NETC#WPFSQL Servervendor plugin APIsHL7 and FHIR where the system exposes them

A first engagement

A short discovery, usually two weeks, where we sit with clinical and admin staff and map the task as it is actually performed. We come back with a scoped build for one workflow, sized so it can be released and judged within a quarter. Nothing goes near live patient data until the access and audit questions are answered in writing.

What comes up repeatedly

  • Planning happens in enormous spreadsheets that only one person fully understands, and that person eventually leaves.
  • Forecast, actual and plan figures live in different places, so meetings start by reconciling numbers instead of making decisions.
  • Seasonality and promotional calendars break naive forecasting models, and planners know it, so they override the system and stop trusting it.
  • Data volumes are large enough that a badly written report can lock a table for everyone.

What we build for it

  • Assortment and range planning tools with scenario comparison
  • Inventory and replenishment systems with configurable rules per category
  • Forecasting support that shows its working, so a planner can see why a number moved
  • Reporting layers that reconcile to one source
  • Bulk import and export paths, because planners will always want a spreadsheet round trip

Typical stack

.NETC#WPFSQL Serverstored procedures and query tuningExcel interopPower BI feeds

A first engagement

We take one planning cycle and rebuild it exactly as it runs today, spreadsheet quirks included, so the output can be compared line for line. Once the numbers match, we start improving the process. Planners keep their spreadsheet in parallel until they choose to stop using it.

What comes up repeatedly

  • A standard LMS covers eighty per cent of what an institution needs and blocks the remaining twenty, which is usually assessment, reporting or enrolment.
  • Enrolment data lives in a student information system that was never designed to talk to a learning platform.
  • Term start creates a load spike an order of magnitude above normal, on a fixed date that cannot slip.
  • Accessibility is a legal requirement, not a nice-to-have, and most off-the-shelf themes fail it.

What we build for it

  • Moodle deployment, theming and plugin development
  • Custom assessment, grading and progress-tracking features
  • Enrolment and single sign-on integration with student records
  • Course authoring and content delivery tooling
  • Reporting for completion, engagement and compliance training

Typical stack

MoodlePHPLaravelMySQLJavaScriptLTISAML and OAuthSCORM

A first engagement

A gap analysis against the platform you already run: what is configuration, what needs a plugin, and what is genuinely custom. We build the smallest thing that unblocks the current term, then plan the rest around the academic calendar rather than ours.

What comes up repeatedly

  • A very small team runs processes designed for a larger one, so automation matters more here than anywhere else.
  • Budgets are project-funded and time-boxed, which means the work has to be useful in phases and cheap to run afterwards.
  • Systems accumulate through donation and grant conditions, so the toolset is fixed and awkward.
  • Staff turnover is high and handover documentation is often the difference between a tool surviving and being abandoned.

What we build for it

  • Automation pipelines that remove recurring manual work: reporting, imports, notifications
  • Content and publishing tooling for lean communications teams
  • Workflow tools for applications, cases or volunteer coordination
  • Data consolidation across donated or grant-mandated systems
  • Simple internal dashboards that non-technical staff can read without training

Typical stack

PythonNode.jsAzure FunctionsWordPressPostgreSQLZapier-style connectorsGoogle Workspace APIs

A first engagement

We look for the single most repeated manual task and automate that first, usually inside a few weeks. It pays for itself in staff hours and it gives the board something concrete before the next funding conversation. Running costs are quoted alongside the build, because a tool nobody can afford to host is not a tool.

What comes up repeatedly

  • The floor is not an office. Connectivity is patchy, machines are old, and a browser tab is the wrong interface for someone in gloves.
  • Job status lives on printed sheets, so the office is always working from yesterday's picture.
  • Design and specification files are large, versioned informally, and the wrong revision reaching the floor is expensive.
  • Production data has to survive a shift change, a power cut and an operator who has no interest in software.

What we build for it

  • Desktop production and job-tracking tools that work offline and sync later
  • Design and specification tooling, including pattern, layout and costing calculations
  • Shop-floor data capture with barcode or scanner input
  • Machine and process reporting for supervisors
  • Bills of material and job costing linked to the office system

Typical stack

.NETC#WPFSQL Serverlocal sync storesbarcode and label printingfile and image processing

A first engagement

One shift, one process. We instrument a single production step end to end so supervisors get a live picture of it, then extend once operators are using it without being asked. Everything we build assumes the network will drop, because on a factory floor it will.

What comes up repeatedly

  • Individual items are unique, high value and described by many attributes, which breaks ordinary product-catalogue thinking.
  • Grading, certification and valuation details have to be attached to a specific item and stay attached through every movement.
  • Stock moves between locations, consignment and memo arrangements, so possession and ownership are different questions.
  • The trade runs on documents, and reconciliation at month end depends on those documents matching the system.

What we build for it

  • Item-level inventory with attribute-based grading and certification records
  • Consignment, memo and approval tracking, including what is out and with whom
  • Valuation and pricing tools with a documented calculation trail
  • Document generation for certificates, invoices and movement records
  • Internal operations and reporting for a small office handling high-value stock

Typical stack

.NETC#WPFSQL ServerPDF and document generationbarcode and RFID inputaudit logging

A first engagement

We model a single item's full lifecycle first: intake, grading, movement, consignment, sale. Get that right and the rest of the system follows. Audit history is built in from the beginning rather than added later, because in this trade the history is the asset.

What comes up repeatedly

  • B2B pricing is not a price list. It is customer-specific, volume-banded, contract-bound and full of exceptions.
  • Orders arrive by email, phone and PDF, and someone in the office retypes all of them.
  • Credit limits, payment terms and stock allocation have to be checked at the moment of ordering, not afterwards.
  • Dealers have long-standing habits, so a portal has to be obviously faster than emailing before they switch.

What we build for it

  • Dealer and distributor portals with customer-specific pricing and catalogues
  • Ordering platforms with credit, stock and allocation checks at order time
  • Quote and approval workflows for negotiated business
  • Order status and shipment visibility pulled from the ERP
  • Reordering tools built on the dealer's own purchase history

Typical stack

ASP.NET CoreAngularReactSQL ServerERP and accounting APIspayment gatewaysEDI where it exists

A first engagement

We start with the pricing engine, because everything else depends on it and it is where the surprises live. Then one dealer group goes live in parallel with email ordering. When they stop emailing, we roll out wider.

What comes up repeatedly

  • Fee earners will not use a system that costs them recordable time, so anything internal has to be faster than the habit it replaces.
  • Client confidentiality and matter separation constrain access design from the start.
  • Document volume is the real workload: templates, versions, approvals and retention.
  • Practice management software is entrenched and expensive to replace, so new tools have to work alongside it.

What we build for it

  • Internal portals for matter, project or case information
  • Client-facing portals for document exchange and status
  • Document generation and template management with version control
  • Back-office automation: onboarding, billing preparation, compliance checks
  • Reporting for utilisation, pipeline and matter progress

Typical stack

ASP.NET CoreNext.jsTypeScriptSQL ServerSharePoint and Microsoft 365 APIsdocument generationSSO

A first engagement

One workflow, chosen because it wastes the most fee-earner time. We measure how long it takes today, build the replacement, and show the difference. Access and confidentiality rules are agreed with your risk people before we write anything.

If you read your own sector above and recognised the problems, that is the conversation worth having.

Book a free consultation