Software Engineer

About Atlas Medical Data Group

We are a founder-owned portfolio of healthcare businesses. The anchor is a healthcare price intelligence company that processes the price transparency files insurers are required to publish. These files disclose the rates they have negotiated with providers but are so massive and messy that almost no one can use them. We build the technology to turn the raw data into price intelligence, which has powerful applications across the US healthcare landscape.

One of the first applications is on the care delivery side. We own and operate a multi-site ABA therapy provider we acquired this year. The data shows us where clinics are leaving money on their commercial contracts. We buy or partner with them, help them close that gap, and run their back office through our management services organization, which we're building to serve providers beyond our own.

About the role

We are hiring a software engineer to build and run the internal applications that support ABES, an ABA therapy practice with two clinics in Illinois, and the management services organization (MSO) that will provide ABES and future practices with their non-clinical operations. The role sits with the operations team and works directly with the people who run the practice on real workflow problems: referrals and intake, authorizations, scheduling, billing and collections, and the reporting that runs on top of them.

ABES is the first practice in a portfolio that intends to grow. We expect to bring additional ABA practices into the portfolio and to offer the MSO's services to practices outside it. The applications this person builds are meant to run across many practices, not only ABES, and this is the first dedicated engineering hire on that platform.

ABES provides ABA therapy to children with autism and their families. The software available to practices like ABES is poor, and the cost of that lands on clinicians, who spend time on administration that should go to clients, and on families, who wait longer to get into care. Better tools change both.

Why this role exists

• The off-the-shelf software available to ABA practices (practice management, claims, scheduling) does not serve ABES well. We intend to replace or supplement those systems with purpose-built tools, using AI tooling and open source where it fits, rather than keep configuring vendor software.
• The MSO will provide billing, credentialing, scheduling, finance, and reporting services to ABES and to other practices that join the portfolio. The applications and data that support those services are being built now, and the design has to anticipate more than one organization.

What you will do

• Build internal applications end to end: understand the operational problem with the people who do the work, design the solution, build the data model, back end, and front end, deploy it, and support it in production.
• Work the practice's core workflow one capability at a time, following the client journey with priority going to the current pain points: outreach and referral management, intake and benefits verification, authorizations, clinic scheduling (a first application is already in place), session documentation through to claims, billing, payment posting, and collections, and operational reporting over each of the above.
• Automate manual and repetitive operational work where a purpose-built tool, a script, or an AI-enabled workflow does the job better than the current system.
• Integrate with the systems that stay in place (ERPNext, the practice management and claims systems, payer portals) where needed. Most of the work is tailoring applications to ABES's use cases rather than integration, but some integration is unavoidable.
• Build on the established platform: deploy following the patterns in place, write deployment scripts and small infrastructure changes when needed, and contribute to the data warehouse as applications create or consume data.
• Use AI developer tooling as a normal part of how you build, and build applications that make use of AI where it adds something for the operators.
• Partner with business operations on product decisions. The business owns prioritization and most of the product management; you own how it gets built and that it works.

Who we are looking for

• A full-stack software engineer. Comfortable across data, back end, front end, and deployment. Depth in one area and working competence in the rest is fine.
• 3-7 years building and shipping web applications.
• Has shipped applications that real users depend on and has supported them after launch.
• Works well with ambiguity. Can take a loosely defined operational problem, ask the right questions of the people doing the work, and get to a usable first version quickly.
• Biases toward getting a working tool into the hands of the business and improving it from there, rather than building the complete version before anyone sees it.
• Healthcare, revenue cycle, or ABA experience is helpful but not required. Experience working with healthcare data or protected health information under HIPAA is preferred. Willingness to learn the domain by sitting with the operators matters more.
• Comfortable working remotely with a small, distributed team and communicating clearly in writing.

What the role offers

• You own what you build end to end, from the first conversation with the operators through design, build, deployment, and support. There is no hand-off to another team.
• You ship to real users on short cycles. The people using what you build are a few steps away, and feedback comes back the same week.
• The technology stack is yours to shape. Languages, frameworks, and tooling for new applications are your call based on what is being built, and AI developer tooling is a normal part of how we work.
• The role grows with the business. As the portfolio adds practices and the engineering footprint grows with it, the person in this seat is positioned to lead that work.

What is hard about it

• Small team. You will be the engineer on most of what you build, and there is no larger engineering organization behind you to lean on.
• Healthcare. The applications handle protected health information, and HIPAA and payer requirements constrain how things get built, deployed, and accessed.
• Vendor systems. The practice management, claims, and payer systems ABES uses today are poor and will not go away all at once. Some of the work is living with them and integrating around them while replacements get built.
• Ambiguity. Requirements come from operators describing their work, not from a product team with written specs. Part of the job is doing that translation yourself.

Technical environment

• Applications have been deployed on Azure Container Apps so far, and we expect to follow established or emerging patterns as we stand up and expand the technical capabilities and infrastructure.
• Data warehouse on Azure; multi-organization support still to be designed.
• ERPNext as the ERP and finance platform.
• Existing clinic scheduling application as the reference pattern for build and deploy.
• Languages and frameworks are not fixed. Existing code is largely Python (data engineering, the scheduling app, and ERPNext), and choices for new applications are at the engineer's discretion based on what is being built.
• AI developer tooling (Claude Code or equivalent) in daily use.

Logistics

• Location: remote, US-based.
• Employment type: full-time employee.