NASFAA
24 badge types in three months — 52,000 recipients, no registration failures
52,000
Recipients onboarded without a registration failure
24
Badge types configured in three months
0
Recurring platform license fees
Practice
The people who ask the questions are the people who build it
Software written for your rules rather than configured around someone else's — by a team that does its own discovery, so nothing is lost in a requirements document on the way to being built.
Our platform
Lighthouse
A content and CRM platform we built and keep current, so a new system starts at roughly the shape it needs instead of at nothing.
Most content platforms are bought whole and used in part. Lighthouse works the other way round: it is a base template we maintain, which each engagement is built out from and around how that organization actually works. The client gets everything they would expect of a CMS — pages, content, images, media, the areas their own team owns — without a second half of the product they are paying for and never open.
It runs on ASP.NET with an Azure SQL back end, on a client's own server or in their cloud tenancy. The architecture is decoupled and API-based: the interface, the middle layer and the database meet at boundaries that were designed to be crossed. That is what lets a front end be rebuilt without touching the back end, and lets us keep the base current with each technology release so an upgrade can be scheduled rather than survived.
The client owns the result. A Lighthouse system is licensed to the organization it was built for — a one-time build cost rather than a recurring license, with no renewal and no obligation to keep working with us. If they want another firm to take it on, they can.
Nearly every custom software client we work with runs on it in some form. The exceptions are engagements that were never about content or membership in the first place, such as robotic process automation and the data and AI work we do inside somebody else's estate. Our other practices work on whatever platforms a client already runs.
There is a longer argument for this, including where it is the wrong answer, in Nobody evaluates year five.
What this covers
The work itself
Application development
Complex business rules and process flows converted into systems — data management, dynamic reporting, content management and commerce processing.
AI products & agents
Automated workflows, agents and assistants, chatbots and predictive analytics — on your own data, for your own members.
Product engineering
MVP through post-release support, with code review, benchmarking and scalability testing built into every stage.
Integration & modernization
Legacy platforms and modern tools connected — single sign-on, payments, maps and analytics — with the data kept consistent.
What that involves
Application development
Complex business rules and process flows turned into systems — data management, dynamic reporting, content management, commerce processing. The rules get written down before they get written in code, which is frequently the first time they have been written down at all.
AI where it earns its place
Automated workflows, agents and assistants, chatbots and predictive analytics, on your own data and for your own members. Applied where a task is genuinely better handled by a model than by rules — and not where it merely demonstrates well.
Product engineering
MVP through post-release support, with code review, benchmarking and scalability testing built into every stage rather than scheduled for the week before launch.
Integration and modernization
Legacy platforms and modern tools connected — single sign-on, payments, maps, analytics — with the data kept consistent across both while the system being replaced is still in use.
Reporting and data
Reporting is usually where a data problem first becomes visible, so it is rarely separable from the application work that caused it. We build the reporting layer as part of the system, not as a later project.
Handover and documentation
Written so that another firm could take the system on. A codebase you own but cannot hand to anybody else is only nominally yours.
The problem
Configured around somebody else's rules
Most organizations do not need software written from scratch. They need the part that is genuinely theirs — eligibility, renewals, approvals, the exceptions that exist for a reason — to stop living in three spreadsheets and one person's head.
A platform will cover most of it. The remainder is where your organization actually differs from the one the product was designed for, and that is where the trouble starts: the rules get bent to fit the software, a workaround becomes policy, and five years later nobody can tell which constraints came from the business and which came from the tool.
The parts that really are the same everywhere — pages, members, events, payments — should not be written from scratch, and we do not write them from scratch. That is what our own platform is for. The custom work goes where the organization is actually different, which is usually a much smaller surface than anybody expects, and the only part worth paying to have written.
How it runs
The sequence
MVP through post-release support. The shape below is consistent; the length depends almost entirely on how much of your rulebook is written down when we start — which, in our experience, is less than anyone expects.
Phase 1
Discovery
The same structured discovery we run as a consulting engagement, pointed at one system instead of a whole estate: who does what, what feeds it, where the exceptions are, and which rules people follow without being able to state them. Run by the people who will build it, so nothing has to survive translation into a requirements document and back out again.
Phase 2
Model, then prototype
The data model first, because it is the decision that is expensive to revisit later. Then a working interface over it early enough that your team can react to something real rather than to a specification — which is the only reliable way to discover that a requirement was wrong.
Phase 3
Build in increments
Code review, benchmarking and scalability testing at each stage rather than as a phase bolted on before launch. Working software on a regular cadence, so the thing being reviewed is the system rather than a report about it.
Phase 4
Integration and migration
Usually the harder half. Single sign-on, payments, and the records that have to stay consistent across two systems while the old one is still running. This is where a build meets the undocumented seams between platforms, which is exactly the thing discovery was for.
At handover
Handover
Documentation, the deployment path, and a walkthrough with whoever will own it afterwards. A system is only yours in a meaningful sense if somebody other than the firm that built it can pick it up, so we treat handover as part of the build rather than as something negotiated at the end of it.
How we choose technology
Deliberately unexotic
The temptation on a new build is to reach for whatever fits the problem most elegantly in the abstract. The more useful question is what you will be able to operate, staff and upgrade in five years, once we are no longer the ones doing it.
An ordinary database doing the clever work.
On a recent build the obvious choice was a specialist graph database. We installed it, kept the seam open — and then ran the actual queries as recursive statements over ordinary relational tables. The client gets graph behavior without betting read performance, operability and hiring on an engine nobody on their team has ever run. If the specialist option ever becomes the right answer, swapping to it is a contained change. If it never does, nothing was lost by not starting there.
One codebase, two runtimes.
A single builder constructs the identical application for the cloud deployment and for a server running inside a client's own network. The same code runs in either, without a rewrite and without a second version to keep in step — which matters when the systems it has to reach are on-premises and are going to stay there.
The test is whether somebody else could run it.
Each of those choices is the same decision wearing a different costume: prefer the option the client can hire for. A clever stack that only we can staff is a form of lock-in we never told you we were selling, and it is no less binding for being technical rather than contractual.
Proof
What this practice has produced
National Association of Home Builders
Guardrails instead of a style guide — three conference sites live in four months
3
Conference sites launched since June 2026
What you gain
The difference it makes
Software that matches the rulebook
Your exceptions are implemented rather than worked around, so nobody has to remember which constraints are real and which are the software's.
A rulebook that exists
Discovery usually produces the first written account of how your own process actually works, exceptions included. That document tends to be useful well beyond the system it was written for.
An upgrade you can schedule
Decoupled and API-based, so an interface can be rebuilt without touching the back end and a technology upgrade is planned rather than survived.
No renewal to negotiate
A one-time build cost rather than a recurring license, on a platform licensed to the organization it was built for.
Skills you can hire for
.NET, React, SQL. Deliberately ordinary, so the people who can maintain this exist outside our building — which is the only version of "you own it" that means anything.
One team from question to code
The discovery and the engineering are the same people. No handoff document, no requirements translation layer, and no gap between what was learned and what got built.
Sectors
Where we apply it
- Nonprofit & AssociationsMembership, certification, chapters and events — the platforms a mission-driven organization runs on.
- HealthcarePatient communities, provider directories, and the compliance that has to hold underneath them.
- EducationCourse delivery, credentials, and the directories that outlive every redesign.
Reference
What we build on
Our own platform
Lighthouse is ours. Most client content and CRM systems we run start from its base template rather than from a blank page, which is why it sits above the rest of this list rather than inside it.
- Lighthouse
Languages & frameworks
What the applications are actually written in. The long-running systems are .NET; the interfaces people use are React or Angular, with Next.js on newer work.
- .NET
- React
- Angular
- Next.js
- Node.js
- Python
- Tailwind CSS
- Bootstrap
- WordPress
Cloud platforms
Where it runs. Most client systems sit in Azure, which is also where the data and AI services below live.
- Microsoft Azure
- Amazon Web Services
- Google Cloud
- Vercel
- Supabase
Data & reporting
The layer underneath. Reporting is usually where a data problem first becomes visible, so it is rarely separable from the application work.
- SQL Server
- Azure SQL
- Azure Data Factory
- Microsoft Fabric
- Snowflake
- Power BI
AI services
Added where a particular task is better handled by a model than by rules. Managed services rather than models we host ourselves.
- Azure OpenAI
- Azure AI
- Amazon Bedrock
- Claude Enterprise
Association management systems
Associations run on an AMS, and the custom work is almost always around it rather than inside it — member portals, event and registration systems, and the integrations that keep one record of a member.
- iMIS
- Personify
- Impexium
- re/Members
Business systems we build alongside
Custom software rarely arrives at an empty estate. These are the systems a new application has to exchange data with, and in some cases extend directly.
- Salesforce
- Salesforce Apex
- NetSuite
- SuiteScript
- SAP
- MFG/PRO (QAD)
Integration & delivery
Moving data between systems that were never designed to talk to each other, and getting releases out without a weekend.
- MuleSoft
- Stripe
- Docker
Automation
For work that is repetitive, rule-bound and currently being done by a person.
In their words
What clients say
They took the time to understand exactly what was needed and built the functionality, rather than delivering a cookie cutter solution.
Ecosystem Investment Partners Modern Signal significantly enhanced our site to be more efficient and user-friendly. Excellent service, timely and cost-effective.
Center for Medicare Education Their team was responsive through all phases of our project and delivered quality work on time and on budget. I would work with them again.
National Center for Safe Routes to School I felt as if my company was their only client. They responded to my needs quickly and efficiently despite short turnaround time and intense demands.
Teaching Strategies, Inc.
Before you ask
Questions we hear
Isn't custom more expensive than buying a platform?
Up front, often yes. Across its life, frequently not — because the comparison people skip is what a platform costs in licenses, in annual upgrades, and in the accumulated workarounds where the product does not fit. The honest version is that custom is the wrong answer when your process genuinely is the same as everybody else's, and we will tell you when we think that is the case.
What happens if we want to work with somebody else?
You can, and nothing in the arrangement is designed to make that difficult. What we build is licensed to you, handover documentation is part of the work rather than an afterthought, and the technology choices are deliberately ordinary for the same reason — standard skills you can hire for rather than a stack only we can staff.
How do you use AI?
Where a task is genuinely better handled by a model than by rules: classification, extraction, summarization, and assistants working over an organization's own content. Managed services rather than models we host ourselves, because running your own is a commitment most organizations should not be making. We are not interested in putting a model somewhere it demonstrates well and performs badly.
What about the systems we already have?
Custom software almost never arrives at an empty estate, so integration is usually the harder half of the build. We map what exchanges data with what before designing around it — the same dependency work we run as a consulting engagement, pointed at one system rather than the whole organization. The seams between platforms are where the surprises live, and they are cheaper to find in discovery than in a cutover.
Thinking
From this practice
Talk to someone who runs Custom Software & AI Development
Two or three sentences about what you run is plenty to start with.