When a website isn't enough
Custom web applications for organizations that need software shaped around how they actually operate. Member portals, dashboards, intake systems, directories, learning platforms, and the workflows that don't fit a template.
When custom is the right call
Most organizations should not build custom software. Off-the-shelf tools are cheaper, faster to deploy, and someone else maintains them. We've talked plenty of prospects out of a custom build and into adopting a tool that already exists. That conversation is free.
When custom does make sense, it's usually one of these situations:
Your team is running on spreadsheets and disconnected tools, and the inefficiency is now expensive
You've evaluated three or four off-the-shelf options and none of them fit how you actually work
You have a workflow that's a real competitive advantage, and you don't want to bend it to fit a SaaS product
You're building something a customer or partner will use directly, and you need full control over the experience
You've built a proof of concept with AI-generated code or a no-code platform and it got you to the idea, but now you're hitting the ceiling on what it can do
You're launching a startup or a new product and need software that can grow with it from the start
If your situation matches one of those, custom is probably worth scoping. If not, we'll tell you and help you find a better and more effective way to your goals.
What we build
Member portals
Communities, alumni networks, donor portals, customer accounts.
Dashboards
Internal admin, operational reporting, custom analytics, multi-tenant admin.
Directories
Searchable, filterable, structured-data sites where the data itself is the product.
Intake & application systems
Forms, qualifications, scoring, workflow automation, document handling.
Learning platforms
Course delivery, progress tracking, certifications, and cohort management.
Hardware integrations
Connections to physical systems for data collection, monitoring, and operational automation.
Custom storefronts
When Shopify or similar doesn't fit: specialty pricing, complex configurators, regulated products.
Internal tools
The custom application your ops team needs that no vendor has built yet.
How we approach a custom build
Custom application work runs in phases. The phases overlap and adapt to your situation, but the shape is consistent.
We sit with the team that will use the software. We watch the current process. We name what's actually happening, which is often different from what the brief says is happening.
Length: 1-3 weeks
Output: A written requirements document, a recommended scope, and a pricing range for the build. Sometimes the output is a recommendation to use an off-the-shelf tool instead.
We work in two-week sprints. At the end of each sprint, you get a recorded demo of what we built. You can shape the priorities for the next sprint. Most clients do. Big direction changes require a scope conversation; small priority shifts happen naturally sprint to sprint.
Length: 6-20+ weeks
Output: A codebase that you understand and own that was shaped with your input through our care.
Deployment, training for your team, written documentation, and a thirty-day stabilization period where we fix anything that surfaces.
Length: 4 weeks
Output: Live platform with documentation and an entire month of close monitoring and tweaking.
Most applications need ongoing care: feature additions, bug fixes, integrations as new tools come up. This typically transitions into a retainer sized to match the application's complexity and your update cadence.
Not sure if you should build? Start with Discovery.
Before any build starts, there's a Discovery phase.
For many prospects, it makes sense to run Discovery as a standalone engagement before committing to a build. Here's what Discovery includes:
Structured interviews with the team that will use the software
Documentation of the current workflow and where it breaks down
A written requirements document with scope options
A pricing range for the build phase, along with what's driving each scenario
An honest recommendation on whether to build, when to build, or whether a different tool is the right answer
What it costs
Discovery is a fixed-fee engagement: $2,500 to $4,500 depending on the complexity of the workflow and the number of stakeholders involved.
What you get
A clear picture of what you'd be building and what it would cost, or a well-reasoned case for why you shouldn't build it. Either way, you leave with something useful.
Discovery is low-risk by design. If the recommendation is to use Salesforce instead of building something custom, you've still saved yourself from a six-figure build that wasn't the right fit. If the recommendation is to build, you go into that engagement with a scope document, not a vague conversation.
After Discovery
If you decide to move forward with us, the Discovery fee applies toward the build.
What we build it on
Our default
Ruby on Rails for the backend. Stimulus and Turbo for the front end on most builds. React where the application calls for richer client-side state. Postgres for the database. Cloudflare for asset storage.
Hosting
Heroku, Render, or AWS depending on scale and operational preferences. We can deploy to a stack you already use if that fits better.
Platform flexibility
We're happy to build in whatever you already have or whatever your team knows best. Most of our custom work is Rails by default because twenty years in this industry has taught us it ships fast, scales reasonably, and stays maintainable longer than most alternatives. But if you come in with an existing system or a strong platform preference, that's fine too. We'll tell you if we think it's the wrong call for your situation.
What to expect on cost
Focused App
Discovery (standalone):
$2,500 – $4,500
Build:
Starting at $8,500
Standard App
Discovery (standalone):
$4,000 – $6,500
Build:
Starting at $15,000
Complex App
Discovery (standalone):
$7,000 – $10,000
Build:
Starting at $25,000
Most applications transition into a maintenance retainer after launch. See Maintenance for how that works and what it costs.
Honest answers to the questions we get most
- How long does a typical application take to build?
-
A focused application, a simple intake system or directory, usually takes six to eight weeks from kickoff to launch. A mid-size application, a member portal with several integrations, typically runs three to four months. Larger or more complex builds stretch further. The wide range is honest: what drives it is how many edge cases your workflow has and how many integrations are involved. The requirements document from Discovery will give you a tighter estimate for your specific situation.
- What does it cost to build an application?
-
The pricing table above has starting points by application type. Discovery gives you a specific range for your build. For reference: focused applications typically land between $5,000 and $12,000. Member portals and dashboards run $15,000 to $40,000. Larger platforms start at $25,000 and scale from there. We don't give firm quotes before Discovery because scope surprises are expensive for both sides.
- What if we want to change direction mid-build?
-
Small priority shifts happen sprint to sprint. Every two weeks you see what we've built, and you shape what comes next. If you decide a feature isn't worth building, we drop it. If something new is more urgent, we move it up. Big direction changes, where the core architecture or scope needs to change significantly, require a conversation about what that means for timeline and budget. We'll tell you clearly which category something falls into.
- What if Discovery tells us we shouldn't build?
-
Then we'll say so. The goal of Discovery is to find the right answer, not to sell you a build. If there's a tool that already does what you need, we'll name it. If the economics don't work for custom development at your scale, we'll tell you that too. A $3,500 Discovery engagement that saves you from a $50,000 build that wasn't the right fit is a good outcome. We'd rather that than the alternative.
- Can you take over a custom application someone else built?
-
Sometimes. We need read access to the codebase first. Once we've looked at what's there, we can scope what it would take to stabilize it and continue the work. Sometimes the right path is to keep going on what exists. Sometimes it's a rebuild. We'll tell you which, and why, before any work starts.
- Why Ruby on Rails as the default?
-
We've shipped Rails applications that are still running a decade later. That history matters when you're making a long-term technology investment. Rails ships fast, scales reasonably for most of what our clients need, and stays maintainable as teams change over time. It's not the right tool for everything. When it isn't, we'll say so.
- What happens after launch?
-
A thirty-day stabilization period comes with every build. After that, most applications need ongoing care: new features, bug fixes, integrations as new tools come up, and occasional dependency updates to keep everything secure. We typically transition into a retainer sized to match the application's complexity and how often things change.
Wondering if custom is the right call?
A free consultation is the fastest way to find out. We'll talk through your situation, your current tools, and what's frustrating you. We'll be direct about whether custom makes sense or whether a different approach is a better fit.
We've worked with member organizations, healthcare practices, educational programs, manufacturers, and nonprofits on questions exactly like this.