Should a Nature Project Build Its Own Software Team? Costs, Hiring and Maintenance
Weigh an in-house software team for a restoration or carbon project, from salaries, hiring and staff turnover to maintenance, forking open source and the alternatives.
Should a restoration organisation hire its own software team?
Only when software is central to what makes your project different and you can fund a team, not one person, for many years. Spreadsheets are the cheapest start and enough for one site and season, but strain once sites, partners and seasons are joined by hand. For most organisations, we recommend a ready platform that adapts, such as Restoration Scope: we set up field surveys, linked site records, maps and donor portals with you, then maintain and extend them, so you get the fit of custom software without hiring a team.
Disclosure: we're Restoration Scope, and we sell one of the alternatives below, so weigh what we say accordingly. We're also a software team ourselves, so the costs here are ones we pay.
| Restoration Scope | Custom build | Spreadsheets | |
|---|---|---|---|
| Upfront cost | A free pilot, then setup quoted after scoping | Months of developer time before the first field season | Free or already paid for |
| Fits your workflow | Configured around it, and changed as it changes | Exactly, while the team that built it stays | You adapt to rows and tabs |
| Maps, offline field work, photos | Included | Built by your team | Coordinates in columns; photos in folders |
| Sites, partners and seasons | Linked records, one current version | As your team designs them | Joined by hand with lookups |
| Upkeep | Ours, shared across clients | Yours: at least two developers, for years | Yours: someone who keeps the sheets in sync |
| Best for | Most projects past a first site and season | Software that is your project's edge, with long-term funding | One site, one season, a few people |
Restoration Scope is a ready platform, set up with you.
It's a fair question to ask. Off-the-shelf tools rarely fit how a project really works, and spreadsheets strain as the project grows. A team of your own promises software that fits exactly, and AI coding tools make building look easier than ever. The costs below are why we'd still think twice.
Figures checked October 18, 2026 against the sources linked in each section.
What does an in-house software team cost?
Salaries are the visible part. In the US, the median software developer earns $135,980 a year (May 2025). Pay varies widely by country: Stack Overflow's
2025 developer survey puts the global median for full-stack developers at $72,509, from about $14,000 in India to $138,000 in the US.
Salary isn't the whole cost. For private-sector professionals in the US, wages are about 69% of what the employer pays; the rest is benefits and payroll costs. So one US developer costs close to $200,000 a year, before laptops, software licences, hosting and recruiting. AI coding tools add little to that: most individual plans cost $20 to $200 a month, before usage charges.
One developer is rarely enough. Someone has to cover holidays and illness, review code, fix a security problem on a Sunday in planting season, and keep things running when the other person leaves. We'd plan for at least two developers and someone who owns the decisions about what to build. At US rates, the two developers alone come to about $395,000 a year, before that decision-maker, equipment and hosting.
How hard is it to hire and keep developers?
Hiring takes time. For non-executive roles at US organisations, SHRM's 2025 benchmark puts the median time from opening a job to an accepted offer at 44 days. A developer who also understands GIS, offline mobile apps and field operations comes from a much smaller pool, and nature organisations compete for those people with tech companies that often pay more. Most nonprofits start without that expertise: in a
2025 Chronicle of Philanthropy survey, 64% of nonprofit leaders named a lack of in-house expertise as an obstacle, and most nonprofits spend under 3% of their budget on technology.
Keeping them is its own challenge. In the US, people in computer and mathematical jobs have been with their current employer a median of 4.6 years. Restoration and carbon projects run for decades. Over the life of one project, expect to replace your developers several times, and each time, knowledge of why the software works the way it does walks out of the door.
That's the bus factor: how many people would have to leave before nobody understands the system. In a study of 133 popular open-source projects, 65% depended on two people or fewer. A small in-house team is usually at one.
What happens after the software launches?
Launch is the start of the cost, not the end. Robert Glass, summarising decades of studies in Facts and Fallacies of Software Engineering (2002), put maintenance at 40 to 80% of software cost, 60% on average. The IEEE Computer Society's software engineering body of knowledge notes that most maintenance is changes, not bug fixes. Field teams find new needs every season, funders ask for new indicators, and methodologies are revised.
Some maintenance isn't optional:
- Security fixes. Libraries and servers need patching as vulnerabilities are found. An unmaintained system holding landowner records and locations is a liability.
- Phone updates. Google Play requires apps to
target a recent Android version to publish updates, and apps that fall behind stop being available to new users on newer phones. A field app needs work every year even if nothing else changes.
- Hosting and backups. Someone pays for servers, watches them, and tests that backups restore.
- Data formats. Registries, standards and regulations change what they accept, such as the geolocation files the EU's deforestation regulation asks for.
None of this shows up in a project's reports, so it's easy to cut when a budget is tight.
Do AI coding tools change the answer?
They change who can build, and how fast. They don't change what software costs after launch.
Tools such as Claude Code, Cursor, Lovable and Replit write working code from plain-language instructions. In Stack Overflow's 2026 survey, 73% of respondents used coding assistants or agents daily. We use them every day to build Restoration Scope, and they make our small team much faster. People outside software use them too: a monitoring lead at one of our partners built a survival dashboard with one, to work out how their team should see the data.
What AI makes cheap is the first version. The costs in this post stay:
- Someone has to understand the code. AI writes code faster than people can read it. If nobody on staff can explain how the system works, the bus factor is zero from day one.
- Mistakes look right. The top frustration in Stack Overflow's
2025 survey, named by 66% of developers, was AI answers that are "almost right, but not quite". In
Veracode's 2026 tests, only 55% of AI coding tasks produced secure code.
- Feeling faster isn't the same as being faster. In a
2025 trial by METR, experienced developers took 19% longer with AI tools, while believing they had been 20% faster. METR's 2026 update says newer tools probably do speed developers up, but the evidence is weak.
- Maintenance doesn't go away. Security fixes, phone updates, backups and data formats still need someone who knows the system.
Google's DORA research sums it up: AI "amplifies what's already there". An experienced team with good habits gets faster. One person with no reviewer ships mistakes faster.
So AI lowers the cost of a first version and makes a small, experienced team more productive. It doesn't replace the team. Our guide to building a field-data system with AI covers what to watch for: photos, backups, offline collection, security and costs.
When does an in-house team make sense?
There are real advantages:
- Exact fit. The software follows your workflow, not someone else's idea of it.
- Speed of change. Your team can change things the week the field team asks.
- Control. You own the code, the data and the roadmap, and you don't depend on a vendor's priorities or survival.
- Capability. Technical knowledge stays inside the organisation and can shape strategy.
It tends to work when software is part of what you offer, such as a carbon developer whose monitoring method is its edge, when you can fund a team for five years or more, and when someone senior can lead it. It tends to struggle when the team is one person, the budget comes from a single grant, or nobody inside can judge the work.
Can you fork an open-source tool like Terraware?
Yes. Terraformation publishes Terraware's code on GitHub under the Apache 2.0 licence, so you can copy it, change it and run your own version. That gives a team a large head start on seed banks, nurseries and planting sites. Our Terraware comparison covers what it does out of the box.
A fork makes you the maintainer. Terraformation's team is very active: its server and web repositories had about 980 commits between them from mid-July to mid-October 2026, including automated dependency updates. Its README says it isn't asking for outside code contributions for now, and some of its code isn't public yet. So your changes stay in your copy, and each upstream update has to be merged into it, resolving any conflicts with your changes, or skipped. Skip enough of them and you own a separate product.
Forking is a good path for an organisation with experienced engineers that needs deep changes. It isn't a way to avoid having a development team. We'd only recommend it with one in place.
What are the alternatives to building your own?
| Option | Fits | Who maintains it | Watch out for |
|---|---|---|---|
 Restoration Scope: an adaptable platform set up with you | Most organisations: the flexibility of a custom system without building one, adapted to your workflow and grown with it | Our team, shared across many projects | A subscription, and dependence on one partner |
| Free tools: KoboToolbox, ODK, QField, spreadsheets | Small teams, one job at a time | The tool's maker; you maintain forms and the links between tools | Joining data across tools falls on your team |
| A free ready-made platform, such as Terraware | Work that matches its model: seed banks, nurseries, planting and monitoring | The platform's team | Your project adapts to its structure |
| Fork an open-source platform | Organisations with experienced engineers | You | Keeping up with the original |
| Build it yourself with AI coding tools | Prototypes, dashboards and internal tools | Whoever on staff understands the code | Security, backups and offline sync |
| Agency or freelancer build | A one-off tool with a clear scope | Whoever you pay next | Who fixes it in year three |
| A general platform with an implementation partner, such as ArcGIS | Teams already on it, with a partner who knows their work | The platform and the partner | Licences, and a partner to keep |
| In-house team | Software is core and funded for years | You | Cost, hiring and turnover |
Many organisations end up with a mix; in a 2024 NTEN survey, 65% of nonprofits used outside consultants for technology projects at least sometimes. One that works well: a technical person on staff, such as a data or GIS lead, who owns the stack and its data, with tools and partners doing the building and maintaining. Our guide to field-data apps compares the free tools in more depth.
Where does Restoration Scope fit?
We think Restoration Scope is the best fit for most organisations weighing this question. It adapts to each project's nuances and grows with it, holds the whole project in one place, and helps run operations and control costs as well as raise funds and report with transparency, without a development team of your own. We built our business model around that. A subscription keeps the upfront cost low and pays for maintaining the platform over the long term, shared across many projects. A service layer lets us shape it around each project's workflow: its properties, nurseries, planting, monitoring and funders.
| Restoration Scope | Your own developer team | |
|---|---|---|
| Ready on day one |
| Nothing until your team builds it |
| Getting started | Running in one week to one month | Hire first, then build |
| What you pay for | A licence, plus implementation while we build. No per-user fees | At least two salaries, plus hosting and tools |
| Upkeep | Hosting, fixes and support come with the licence | Security fixes, phone updates and backups fall on your team |
| Your data | It’s yours. Download any table or map whenever you want. A regular sync to your own files is an add-on | In a database your team runs |
Once Restoration Scope is running, we make weekly progress on your top priorities; after that, it grows with what you learn and each season.
A property set up around its planting work.
A ready-to-plant checklist for boundary, land tenure, site preparation, seedlings and crew, beside the property's boundary on the map. Demo project: names and numbers are made up.
- Good fit: most organisations, especially those whose workflow doesn't fit a ready-made tool and who don't want to hire and keep a development team.
- Think twice if: software is your product and you need full control of the code. Then build a team, or fork open source with one.
Whoever you choose, us included, ask how you get all your data out, and in which formats, before you sign.
How do you decide?
Answer these honestly before posting a job:
- Is software what makes your project different, or a tool to run it? Build what makes you different; buy the rest.
- Can you fund at least two developers for five years? If the money comes from one grant, plan for what happens when it ends.
- Who fixes it in the middle of planting season? Name the person, and their backup.
- What happens when your lead developer leaves? If the answer is "we start again", the risk is too high.
- Can you describe your workflow on one page? If not, start there. No team, in-house or outside, can build what nobody has written down.
Software is a long-term commitment, like the trees. Choose the option you can keep looking after. For why we think tools should serve operations first, see Reporting vs. Operations.
Frequently asked questions
How much does an in-house software team cost?
In the US, the median software developer earns $135,980 a year, and wages are about 69% of what an employer pays for a professional, so one developer costs close to $200,000 a year with benefits. We'd plan for at least two developers, so one person's absence or departure doesn't stop the software, plus hosting, tools and someone who decides what to build.
Can one developer be enough?
Only for a while. One developer is a single point of failure for holidays, illness, security fixes and resignation. In the US, people in computer and mathematical jobs have been with their current employer a median of 4.6 years, so a project that runs for decades should expect to replace its developers several times.
Can we fork Terraware or another open-source tool?
Yes. Terraware is free to use as it is, and its code is on GitHub under the Apache 2.0 licence, so you can also fork it and change it. You then maintain your version yourself, and Terraformation's team updates its code on most working days, so keeping up with the original is ongoing work for experienced engineers.
Is it cheaper to build software or buy it?
Building often looks cheaper at the start, but most software cost comes after launch. A widely cited estimate puts maintenance at 40 to 80 percent of total cost, 60 percent on average. When you buy, that upkeep is shared across the vendor's customers and paid for through fees, so compare the full cost over several years, not the launch cost.
Can AI coding tools replace a development team?
Not for software that holds field data for years. AI tools make a first version cheap and can make experienced developers faster, but someone still has to understand and review the code, fix security problems, keep backups and maintain the system. Use them to prototype and to make a small team more productive.
What should we ask a software partner before signing?
Ask who maintains the software and for how long, how you get all your data out and in which formats, what happens if the partner closes, how changes to your workflow are priced, and whether your field team can keep working offline.
Another question? Email us or book a call.
