Most of the software we build is for businesses — things that help a company make money or run better. COMPASS for Autism was different. It's a clinical research platform we built for autism services research at Ball State University, used by researchers, consultants, educators, and families across the US.
Building software for research, and specifically for autism research involving families and children, taught us things that building business software never did. I want to share what I learned, because clinical and academic research software is a real and underserved area, and there's very little honest writing about how it actually gets built.
What a clinical research platform actually does
Research software isn't one thing — it depends on the study. COMPASS supports autism services research, which means it has to serve several very different kinds of people, all interacting with the same underlying data in different ways.
There are researchers who design and run studies and need to collect and analyse data. There are consultants and educators who work directly with the people in the study and need to record observations and track interventions. And there are families — parents and caregivers of autistic children — who provide information and engage with the research that affects their kids.
Each of these groups needs a completely different experience of the same system. A researcher needs powerful data tools. A family member needs something simple, gentle, and clear. That's the central challenge of research platform software: one system, deeply different needs.
The engineering challenge: multi-role done properly
The biggest technical challenge in COMPASS was the role system. Not because roles are hard in principle — lots of apps have user roles — but because these roles are genuinely different, not just "admin sees a few more buttons."
A researcher logs in and sees data collection tools, study management, and reporting. A consultant logs in and sees the people they're working with and the observations they need to record. A family member logs in and sees something simple, focused on their own child, free of the complexity the researchers deal with.
Building this properly means designing the system around roles from the very start, not bolting permissions on at the end. The data model has to understand who can see what. The interfaces have to be genuinely different per role, not the same interface with things hidden. And the whole thing has to keep each person's data appropriately separated and protected.
This is where a lot of multi-role projects go wrong. Teams build one interface and try to hide parts of it per role. It produces a confusing experience for everyone and a security model full of holes. The right way is to design each role's experience deliberately, on top of a data model that understands the relationships between them. It's more work upfront. It's the only way that actually works.
Why research data is different from business data
In a business app, if a data point is slightly off, someone fixes it and moves on. In research, the integrity of the data is the entire point. The conclusions of the research depend on it. Bad data isn't an inconvenience — it can invalidate findings.
That changes how you build. Data collection has to be structured and validated carefully. You can't let bad data in casually and clean it later, because in research the data is the product. You design the collection process so the data comes in clean, consistent, and reliable, because researchers are going to draw real conclusions from it.
There's also the matter of how research data accumulates over time. A study runs for months or years. The data builds up, and the system has to handle that growing body of information in a way that stays organised and analysable. You're not building for a snapshot — you're building for a longitudinal record.
The part that mattered most: building for vulnerable participants
COMPASS involves autistic children and their families. That's not an abstract user base — those are real, vulnerable people, and the software touches sensitive information about them.
This shaped everything. The family-facing parts of the platform had to be gentle, clear, and respectful. A parent of a recently diagnosed child is dealing with a lot. The last thing they need is confusing, cold, clinical software. The interface had to feel like it was built by people who cared about the families using it — because it was.
The data protection had to be serious. Information about children, about disabilities, about families — handled with real care, proper access controls, and a clear understanding of who should see what. This isn't a checkbox. When you're holding data about vulnerable children, getting it right is a genuine responsibility.
Building this taught me something about software I hadn't fully appreciated. The same care you'd want a person to show toward a vulnerable family, the software has to show too. Every confusing form, every cold error message, every place where the experience is harder than it needs to be — that's a small failure of care toward someone who deserved better. Building COMPASS made our whole team better at thinking about the human on the other side of the screen.
What it costs to build research software
Honest ranges for clinical/academic research platforms:
| Scope | Typical cost | Timeline |
|---|---|---|
| Focused study platform (1-2 roles, data collection, basic reporting) | $30,000–$70,000 | 16–24 weeks |
| Multi-role research platform (data collection, analysis, multiple user types) | $70,000–$150,000 | 24–40 weeks |
| Enterprise research system (compliance, integrations, multi-study) | $150,000–$350,000+ | 40+ weeks |
A few things that affect cost specifically in research software: compliance requirements (IRB considerations, data protection, sometimes HIPAA), the complexity of the data being collected, the number of genuinely different user roles, and reporting and analysis requirements. Academic and clinical research often has specific institutional requirements that add scope — worth identifying early.
Should you build custom research software?
It makes sense when your study or research has specific requirements that generic survey tools and data collection platforms don't handle, when you have multiple distinct user types, when you're running longitudinal research that builds data over time, or when the research is significant enough to justify proper software.
It doesn't make sense when a survey tool like Qualtrics or REDCap already does what you need. These exist and are good at what they do. Build custom when your research genuinely needs something they can't provide — complex multi-role interaction, specific workflows, a participant experience that off-the-shelf tools can't deliver.
The honest test, same as always: do existing tools force painful workarounds that get in the way of the actual research? If yes, custom is worth it. If a survey platform would do, use the survey platform.
What I'd tell someone building research software
Design the roles deliberately from the start. Research platforms are multi-role by nature, and the roles are genuinely different. Build each experience on purpose, on a data model that understands the relationships. Don't bolt permissions onto one interface.
Treat data integrity as the core requirement. In research, the data is the product. Build collection to be clean and validated from the start. You can't fix research data quality after the fact the way you can with business data.
Build for the vulnerable participant. If your research involves children, patients, or vulnerable people, the care you'd show them as a person is the care the software has to show too. Gentle, clear, respectful, protective. This isn't soft — it's the actual job.
And take the responsibility seriously. Research software holds data that real conclusions depend on, often about real people who deserve care. Build to that standard.
We built COMPASS for Autism from Lahore, for a university in Indiana, serving families across the US. It's one of the projects I'm proudest of — not because it was technically the hardest, but because it mattered to the people who use it. That's a good reason to build something well.
Muhammad Nabeel is the co-founder of Teamseven. We built COMPASS for Autism — a clinical research platform for Ball State University, used by researchers and families across the US. If you're building research or healthcare software, we'd like to talk.