You've already run the evaluation. Off-the-shelf either failed you or was never going to fit how you work, and the question isn't whether to build — it's who you trust to do it. We do custom software development for nonprofits and ed-tech teams: two-week sprints you can watch happen, on a fixed fee or a monthly team retainer, whichever suits how your funding actually works. When it launches, we stay on to run it.
The risk
Almost nobody gets the call saying the project collapsed. What happens is slower: the budget holds until month four, a requirement surfaces that nobody wrote down, and the conversation about it happens after the invoice. Four ways custom software development goes sideways, none of them dramatic.
You approve a plan and it goes quiet. Weeks pass with status emails describing activity rather than progress, and the first real look is a demo that doesn't match the conversation you remember. Visibility is the difference between custom software development that hits the mark and custom software development that drifts.
A requirement everyone assumed in month one gets written down in month three, and it turns out to be three weeks of work. That part is normal; discovery never fully ends. Finding out on an invoice is not. The failure isn't the change — it's that nobody named the trigger for a change conversation before the work started.
The senior person who understood your program in the sales conversation is on another account by month two, and the work goes to people who never heard it. The requirements document still says what it said. But documents don't carry the reasoning behind a decision, and a team that inherits a spec builds the spec instead of the intent.
Custom software development has an operating cost, and it usually gets discovered rather than planned. Keeping a system current — dependency updates, security patches, the occasional break when a platform underneath it changes — is real annual spend, and it belongs in the budget you present rather than in a surprise the following year. We put a rule-of-thumb figure on it on our custom software development cost page. A proposal that never mentions year two at all is leaving it for you to find.
None of this gets solved by hiring a bigger firm. Bigger firms have more people to rotate off your project and more process between you and the code. What fixes it is a change control process, a working build to review, and an accountable person stepping up — before anyone even opens an editor.
When each one usually surfaces
Work starts. The next thing you see is a demo, and it's weeks out.
A requirement everyone assumed gets written down late — and surfaces on an invoice.
The senior person from the sales conversation is on another account. The spec remains; the reasoning does not.
Operating cost shows up after launch — updates, patches, platforms that move underneath you.
Each one costs more the later it shows up.
Scope
Most of what we build starts the same way: a program that outgrew its tools, held together with spreadsheets, manual re-entry, and one person who knows where everything lives. Here's what a custom software development engagement usually turns out to be.
On the stack: we're wary of anyone who tells you they have one answer, because the right choice for a custom software development project genuinely depends on what you're building and who has to maintain it afterward. The direction we've moved is toward full code and away from low-code platforms — low-code gets you to a working demo fast and then puts a ceiling on everything that comes after it. Most recently that's meant Next.js, with Supabase and Vercel behind it. What matters more than the framework names is that it runs on infrastructure your organization owns, so any competent developer can pick up what we hand you.
A fair amount of what people ask for already exists: if your process is common and your data model is standard, an off-the-shelf tool beats a custom software development project on cost and on time. We built a free five-minute Build vs. Buy Assessment that sometimes tells people not to hire us.
Three or four tools, a shared drive, and a spreadsheet that's really the database — consolidated so data gets entered once and reporting stops being a monthly project.
Software your organization sells, licenses, or delivers services through. The Autism Helper's curriculum platform is this: the product itself, not a back-office tool.
Field staff, volunteers, and participants who need something that works on a phone in a parking lot. We built 4MyCiTy's food-rescue check-in app for that.
We built Decision Studio for the Alliance for Decision Education using OpenAI agents — an AI-powered tool for teachers, inside a product we designed and built. That's the shape we'd recommend: AI doing a defined job inside a product, evaluated on whether the job gets done. We don't sell AI as a service line.
The process
Every phase has a shape, a length, and something you can look at when it ends. You should never have to ask how it's going, because the answer arrives on a schedule you agreed to before we started.
Before any custom software development starts, we run an intake covering what derails projects later: who can approve scope, what systems you run and who administers them, and what compliance requirements your sector imposes. Then we assemble the team, set up environments and access, and confirm scope against the signed agreement.
One meeting, both teams, named people on each side. We confirm scope, walk the timeline, and agree the communication cadence in writing: meeting day and time, primary channel, what the written update contains, and who gets called when something is urgent.
Two weeks is our default rhythm for custom software development, adjusted when a project genuinely calls for something else. Each sprint opens with a planning and alignment session and closes with a demo of what got built. In between, you have standing access to staging — not a link we send when we're ready, a login you use whenever you want.
A named person owns QA on every custom software development engagement — not a department, a person, and you'll know their name. Development is test-driven, and the automated test suite is run by AI agents as part of the build cycle rather than as an end-of-project scramble.
You get the repository under your organization's account, the credentials, documentation written as we went, and a walkthrough for whoever fields questions internally. The conversation about what happens afterward is product stewardship — a separate arrangement, not a line item inside your build.
We recommend that Phase 1 of any custom software development project be an MVP: the smallest version a real user can do real work in, shipped early enough that what you learn from it still changes what gets built next. Most clients strain against that, and the reason is fair. You've waited a long time for this, the list of things it should do is long, and a deliberately partial first release feels like paying full freight for half a product. Pushing back on that is part of what you're hiring us for.
It's also an argument we lose more often than we win, and we'd rather say so than pretend otherwise. What actually gets built first usually carries more features than a true MVP should. There's a real reason for it, and it's probably your situation. Building an MVP for a product that doesn't exist yet is comparatively easy — there's no baseline to match. Replacing an existing product that's fallen behind is a different problem entirely: the team is expected to reach feature parity with the thing you already have *and* deliver the new capabilities that made you start the project in the first place. Parity isn't a minimum viable anything. It's the floor.
So the honest version of this phase is a negotiation. We'll argue for the smallest first release we can defend, you'll argue for more, and the answer usually lands between the two. What we won't do is let that conversation happen quietly, in scope creep, after the number is set.
That combination is why written weekly reports often turn out to be unnecessary — clients who sit in sprint planning, watch the demo, and can open staging on a Tuesday afternoon already know where things stand. We'll still write them if you want them, and some boards do. But the point of the arrangement is that you see the work happening rather than receive a document about work that happened.
Custom software development dates are estimates until discovery is done, and we'd rather tell you what moves them: how fast your team gets us decisions and content, how many systems we integrate with, and scope clarifications that surface once people see real screens.
Inside each two-week sprint
Sprint opens with planning and alignment.
Work lands in the sprint with a named QA owner.
Standing staging access — use it whenever you want.
Demo closes the sprint; the next plan absorbs what you learned.
The team
Here's the structure, plainly, because you'd work it out anyway. Fabrik doesn't carry developers between projects. Everyone who builds your software is a contractor, drawn from a stable of vetted senior practitioners — front-end, back-end, QA, Scrum, product, design — with a senior developer holding oversight across the build. A typical custom software development team is three to five people. Nobody on your project is learning to code on your budget, and there's no junior staffing pyramid under the senior names on the proposal.
An agency with payroll has to keep people busy, which creates a quiet incentive to pad scope and stretch timelines to bridge the gap between engagements. We don't have that gap to cover, so the team gets sized to the work rather than to our overhead. Turnover inside a custom software development engagement is uncommon, partly for a structural reason worth naming: our engagements are measured in months, not years, which is a short enough window that the people who start usually finish. What we won't claim is that no contractor ever rotates; on a long build, some do. What is true is that Brad is on your project from the first call to the last, and into stewardship after it. The fear worth having isn't whether a contractor changes — it's whether the person who sold you this disappears.
Your side
Our side
Day to day: your coordinator works with the project team.
Proof
Two custom software development engagements at organizations the size we're built for, neither with a technical team when they started. That's the relevant comparison — not a logo wall of enterprises whose budgets have nothing to do with yours.
Ed-tech curriculum platform rebuilt MVP-first for district security and accessibility requirements.
There's always been a nice open line of explaining why things can work or shouldn't and a lot of back and forth — not just 'Hey, this is what I want,' and build it, because that might not make sense.
Sasha Long, Founder and President · The Autism Helper
how we rebuilt The Autism Helper's platform
Four custom software development engagements since March 2025, including Decision Studio.
The tool itself is a great success, but the process we followed — and the proof to ourselves that we can do it — is almost equally as impactful.
Sarah Smirnoff, Director of Education · Alliance for Decision Education
And a third, briefly: we built 4MyCiTy's mobile food-rescue platform — check-ins three times faster, 5,000+ participants served a month, 4.9 stars in the app stores.
Investment
We're not publishing a number, and we'd rather say so than let you scroll to the bottom looking for one. There are two ways we structure a custom software development engagement, and the choice between them is the single biggest lever on what you'll pay. Fixed fee gives you a firm number that won't change, in exchange for scoping everything exhaustively before we start and change-ordering anything that moves mid-stream. A monthly team retainer gives you a team for an estimated number of months and the room to change direction as you learn, in exchange for a total nobody can state up front.
One thing to clear up, because it's published elsewhere on this site: nearly every engagement starts with a two-week Roadmap Workshop at $7,000. That's the entry point to working together, not the price of a build. Development is scoped and priced separately once we know what we're building, and it's a materially larger number.
Both models with their downsides stated, what actually moves the number, what year two costs, and how grant funding can cover a build — all of that has a page of its own: what a custom software development cost actually depends on. Either way, you'll get an order-of-magnitude range on the first call, before either of us spends time on a proposal.
What to expect
A senior custom software development team of three to five, with a named QA owner and oversight throughout
A working build on your infrastructure at the end of every two-week sprint
Standing access to staging, the backlog, and the ticketing system — not a summary of them
Sprint planning at the start and a demo at the end, every two weeks
Documentation written as we go, not reconstructed the week before launch
An honest read when the answer is "don't build this"
One person who can approve scope without convening a committee
Access to real users, not only the people sponsoring the project
Candid feedback on the sprint build, especially when it isn't right
Content, credentials, and system access on the dates we agree to
Written approval at the end of each phase before we move to the next
A realistic estimate of your team's time — a few hours a week, more around launch
After launch
Software ships unfinished by definition. The first six months of real use teach you things no specification could have, which isn't a scoping failure — it's what happens when the people you built it for finally get their hands on it. We stay through that period as a matter of course. And because we'll still be running this in year three, the architecture calls we make in month one are calls we personally live with. That's a different set of incentives than a firm that hands over the keys at launch, and it's why our custom software development decisions look the way they do. Here's what it involves: product stewardship.
Common questions
Say so on the call — it's a common place to be and it isn't a disqualifier. Some teams arrive with a stakeholder-aligned scope document and go straight into custom software development. Others start with a two-week Roadmap Workshop: user research, a prioritization session, and a roadmap you own regardless of who builds it. It's an on-ramp, not a gate.
More than a subscription, less than hiring a team — which we know isn't the answer you wanted. A real figure depends on the size of the first release, how much is new versus a rebuild, your integration surface, your compliance requirements, and which of the two engagement structures you pick. That question deserved more room than a FAQ answer, so it has a page of its own: custom software development cost, covering both models, what moves the number, and how grant funding covers a build. What we commit to either way is a ballpark range on the first call, before a proposal exists.
A custom software development build typically runs 8 to 16 weeks in two-week sprints, after a two-to-four-week discovery and setup period. Real-time features, several integrations, or migrating messy historical data each extend it. If your timeline is fixed — a school year, a grant period, a board meeting — tell us at the start and we'll scope the first release to fit the date.
Yes, completely, and usually it's in your name from day one. The repository sits under your organization's account, hosting runs on infrastructure you control, and documentation gets written as we go. Any competent developer can pick it up and continue without us. We'd like you to stay because the work is good, not because leaving would be painful.
We'll tell you, and it happens. Usually it sounds like this: your process is standard enough that an off-the-shelf tool does the job for a fraction of the cost, and here's the one we'd look at first. Sometimes the real problem isn't software — two teams disagree about a process, and no custom software development project settles that. The decision underneath all of this — whether you need custom software at all — has a page of its own.
An hour, no commitment, no obligation at the end of it. You'll get an honest read on whether custom software development is the right move at all, a rough sense of scale before anyone writes a proposal, and a straight answer if we're not the right fit. If you'd rather read that part first, whether we're the right fit has its own page.