Part Time Developer for an App You Already Run: What a Month Buys

Your app works. Somebody was paid to fix the thing that was broken, it stayed fixed, and now the same person is suggesting the obvious next step: put them on a monthly arrangement so there is always somebody there.

That is a different purchase from the one you just made, and the difference is worth a few minutes before you agree to it. The job you bought had an end written into it. You knew what finished looked like, because you could see the broken thing working. A month of somebody’s time has no end in it and no named result either. What it buys is availability, plus movement on a queue.

Hiring a part time developer for an app you already run is a real answer to a real problem. It is also the most expensive way to solve a problem that has an end. Some of the work genuinely arrives every month whether you open the app or not, on calendars set by Google, by the Node.js release team, and by whoever publishes the packages your app depends on. The rest of it could sit untouched for a year and cost you nothing at all.

This page separates those two piles, and then gives you the test.

Ongoing developer support buys availability rather than a named result. For one working app it earns the money when real users depend on it and the change list refills faster than it empties. When neither is true, buy the next named job and keep the month. Four kinds of work arrive on somebody else’s calendar regardless.

What you are actually buying when you pay somebody by the month

Four things, and it is worth being able to name all four before you agree to a number.

Availability when something breaks. Somebody answers. Not somebody who fixes it inside an hour, unless that is written down and priced, but somebody whose default answer is yes rather than “I am on another project until the 14th”. For an app with paying users this is most of the value, and it is the part sellers describe least clearly.

Somebody working a queue. You have a list of changes. Copy on a page, a field that should be optional, a report your biggest customer keeps asking for. A month buys hours against that list in whatever order you agree. Nobody promises the list will be empty at the end of it.

The calendar work. Store requirements, runtime versions, dependency alerts, platform changes. This arrives on schedules published by other companies, and the next section is a dated list of exactly what those are.

Somebody who already knows the app. The fourth thing is the one people underrate. A developer who has been inside your codebase for three months can price a change in ten minutes. A new one spends the first two days working out where things live, and you pay for those two days every single time you start over with somebody new.

Now the two things a month does not buy, both of which get implied.

A month does not buy a named result. If you need payments live by the end of October, “a developer for October” is not that promise, and no honest seller will pretend it is. Buy the named thing, agreed in plain words, and let the month be a separate decision afterwards.

A month also does not buy insurance. Availability is not the same as somebody watching. Unless you are paying for monitoring, and monitoring is a specific arrangement with alerts and someone on the other end of them, the way your developer finds out that the app is down is that you tell them.

Paying to have one named feature added to an app that already works is its own job with its own shape, and it is not what a month of availability is for.

The work that arrives whether or not you touch the app

The dated list in this article was built on 26 August 2026 by reading three published schedules that apply to any app on Android, on Node.js or with GitHub’s dependency alerts, Google Play’s target API level page, the Node.js release table and GitHub’s Dependabot documentation, alongside the hire pages of the sellers who rank for this subject, and then setting each recurring item against the severity split of the 958 findings AxonBuild’s audits confirmed across 21 third-party AI-built apps in June and July 2026.

Take the first row. Google Play sets a target API level floor, raises it on an annual cycle, and publishes the date it takes effect well in advance. The effect on an app that falls under the floor is narrow and quiet: it keeps working for everybody who already installed it, and it stops reaching new users on newer versions of Android. A developer who needs longer can apply for an extension, within a window Google also publishes.

Read the shape rather than the numbers, because the numbers move every year and the shape does not. An app nobody updates walks under the floor without an error message and without a support ticket, and what you see is a slow flattening of installs. The levels in force today, the date the next one takes effect and the extension window are all on Google Play’s target API level requirements, read for this page on 26 August 2026.

The second row works the same way. The Node.js previous releases page, read 26 August 2026, publishes a table whose columns are Node.js, Codename, First released, Last updated and Status. In the Status column, v20 is listed as EOL, with 24 March 2026 in the Last updated column, while v22 and v24 both carry the status LTS. The same page states that LTS “typically guarantees that critical bugs will be fixed for a total of 30 months” and that “Production applications should only use Active LTS or Maintenance LTS releases”. If your app was generated eighteen months ago against whatever the builder tool pinned at the time, that line is a real question about your app and not a theoretical one. The current table is on the Node.js previous releases page.

The third row is the one people assume is already handled, because a bot opens the pull requests. GitHub’s documentation on Dependabot security updates, read 26 August 2026, says that alerts “will be closed when related pull requests generated by Dependabot for security updates are merged”, that “For other ecosystems, Dependabot is unable to update an indirect or transitive dependency if it would also require an update to the parent dependency”, and that the updates “may include compatibility scores to let you know whether updating a dependency could cause breaking changes to your project”. Every one of those sentences describes a machine handing work to a person. The pull requests still have to be looked at, judged and merged by somebody, the deeper dependencies are frequently the ones it cannot touch, and a compatibility score is an input to a decision rather than the decision. Automatic updates do not close the loop on their own. GitHub’s Dependabot security updates documentation is the source for all three.

One founder posting publicly about their own project described the shape of this better than any seller page does, while talking about the tooling they had built for themselves rather than about hiring anyone:

Started simple, grew to 100+ Python files, six test suites, multiple dashboards … everything you need to actually maintain something you did not fully write yourself.

That last clause is the honest description of what recurring work on an AI-built app is. The code exists, it works, and nobody in the building has read all of it.

The last row of the table has no schedule at all, which is exactly why it gets skipped in every arrangement priced by the month. A backup that has never been restored proves only that a setting is switched on, and proving more than that takes an afternoon nobody has ever put on a queue. If it is not going to be on yours either, at least do it once yourself: proving a backup actually restores walks the whole thing.

How much of that list is actually urgent

Not much of it, and knowing the proportion changes what you should be buying.

Across the 21 third-party apps in AxonBuild’s findings ledger, the audits confirmed 958 findings in total, which works out at somewhere near 46 to an app. Fifty-eight of the 958 were critical. The remainder divides three ways: 362 medium, then 403 filed as smell and 135 as hygiene. Those counts are computed from the ledger rather than estimated, and each one was checked adversarially against the app’s own code instead of matched to a scanner pattern. The cohort is fixed: 26 real applications reviewed in June and July 2026, 21 of them third-party.

Fifty-eight criticals out of 958 confirmed findings is about six per cent. The rest were real and worth fixing eventually, and almost none of them were going to ruin anybody’s week. A month of somebody’s time buys work against the whole pile. What threatens your app is the small end of it.

The small end is also unusually cheap to close. In the same cohort, 9 of the 26 apps were running a framework release with a break-in path that was already public and reachable in the app, and the audits noted the fix is often a one-line version bump. That is the argument for the calendar work in the previous section, stated as a number: the thing most likely to hurt you is a version that went stale, and the fix is usually one line rather than one month.

The other genuine emergency class in that cohort had nothing to do with versions. Several apps were running against a production database with no staging copy to test against, no working backup, and leftover routes that could destroy data if anybody found them. None of that waits politely in a queue. Establish those before you agree to anything recurring, because they change what a sensible arrangement even looks like.

So the pile splits in two. A short urgent list, mostly version bumps and a small number of genuinely dangerous things, which somebody should close once and then keep closed. And a long slow list that a month of availability grinds through in whatever order suits you. The second list is worth paying for when it is long and still refilling. It is worth nothing when it is eleven items with an end.

When is paying by the month money wasted?

Paying by the month is wasted when any one of three things is true: nobody has read the code yet, the change list has an end you can see, or no user’s day breaks when the app breaks. Each is checkable in a minute by somebody who cannot read code, and any one of them is enough to wait.

Nobody has read the code yet. If no developer has been inside your app, neither of you knows what a month contains. You are agreeing a recurring price for an unknown quantity of work, and the person quoting it is guessing too, which is why the guess is generous. Buy one named piece of work first. The person doing it reads enough of the app to price the next thing honestly, and you find out whether you like working with them on a bill you can see the end of. Whether to pay by the hour or for one named result, and what the published cleanup prices are actually a range of, is answered on what a vibe coding cleanup actually costs.

The change list is short and finite. Write it down. If it comes to eleven things and no twelfth thing suggests itself, buy it as a job with those eleven things in it. The moment to reconsider is when you write the list, work through it, and find it has grown while you were not looking.

Nobody’s day breaks when the app breaks. This is the hardest one to be honest about. An internal tool that four people use, or an app with users who would shrug and come back tomorrow, does not need somebody on call. Availability is the expensive half of ongoing support, and it is only worth the money when an outage costs you something specific: refunds, a churned customer, a customer who tells others.

There is a fourth pattern worth naming, because it gets sold hard: the monthly code review subscription. It is a reasonable product for a team shipping changes every week. For a one-app founder whose app changed twice last quarter, it prices a stream of work that is not flowing. If you are weighing one up, what a monthly code review subscription assumes about your app is the thing to check before you sign.

What goes inside a written monthly arrangement, the hours, the response times and everything sitting outside it, is a separate question from whether you should be paying by the month at all.

When it is worth it

The mirror of the last section, and it is worth being just as unsentimental about it.

Real users depend on the app and an outage has a cost you can name. The test is whether you can finish that sentence with a number in it, as in a Saturday outage costs roughly four bookings. Once you can, availability stops being an abstraction and starts being cheaper than the thing it prevents. If what you are worried about is the app falling over as usage grows rather than a person being unavailable, that is a different diagnosis and which ceiling your app hits first under load is the page for it.

The change list refills faster than it empties. You finish eleven things and there are fourteen. That is what a growing product looks like, and it is the clearest signal that you are buying a stream of work rather than a job. At that point, buying it as a stream costs less than repeatedly negotiating individual jobs and paying somebody to reload the app into their head each time.

Something time-bound needs a person awake for it. A store submission with a deadline, a payment provider migration, a compliance date somebody else set. These do not need a permanent arrangement, but they do need somebody who is not discovering your codebase for the first time on the day it matters.

And the honest third case, which nobody puts on a sales page: you want to stop being the person who gets called. That is a legitimate reason to pay money, and it is worth saying out loud rather than dressing up as a technical requirement. Handing the whole app to somebody else, so that they run it and you stop being the person who gets called at all, is a different purchase from buying a person’s availability, and it has its own four checks that prove the transfer actually happened.

Which of the people around an AI-built app is answerable for it, the builder platform, whoever wrote the prompts, or whoever you pay, is a question about responsibility rather than about what a month of somebody’s time buys.

On-demand developers, dedicated developers and the words sellers use

The buyer-side search results for this subject are almost entirely sellers, and each one has its own phrase. Some write on demand developers, some write on-demand developers, and the hyphen changes nothing about what is being sold. The phrases themselves do mean different things, and two of them do not mean what a one-app founder assumes.

On-demand developers. The clearest published definition comes from ncube, an outsourcing vendor whose on-demand hiring guide, read 26 August 2026, defines a developer on demand as “a team member you can integrate into your permanent team during periods of fluctuating workloads, short-term project needs, or when specialized expertise is required for a limited time”. Read the assumption in that sentence. It assumes you have a permanent team. The same page describes engineers “working exclusively for you 40 hours / 5 days per week”. Almost everything written under the heading hire on-demand developers is written for a company with an engineering department that is temporarily short of people, which is a different problem from owning one app and no engineers. The page is at ncube.com/how-to-hire-on-demand-developers-for-your-it-projects and is named here rather than linked.

Dedicated developers. The phrase hire dedicated app developer means a person assigned to you full time by a vendor and billed monthly, the highest-commitment shape on the market. For one working app it is almost always more capacity than the work justifies, which is why the pages selling it spend their length on team quality rather than on whether you need a full-time person.

Part-time and hourly. This is the shape that actually fits one app. Lemon.io’s part-time hire page, read 26 August 2026, publishes real numbers: “The rates for part-time developers can range from $55 to $65 per hour” and “Senior engineers from $55/hr”, with 2 to 3 matched candidates promised “within 24-48 hours”, “20 extra paid working hours to test the chosen engineers’ skills”, and a replacement at no charge if you want a different developer. Those are that seller’s own published terms on that date and nobody else’s, and a marketplace’s advertised band is not a market rate. The page is at lemon.io/hire/part-time-developers/, named and not linked.

Two of the sellers on this subject publish nothing an automated read can reach. Toptal’s public FAQ page returned HTTP 403 on 26 August 2026, and so did Upwork’s own on-demand developers hire page, so nothing at all is claimed here about the terms either of them publishes. The two addresses are toptal.com/faq and upwork.com/hire/on-demand-developers/, named rather than linked, and both were re-probed the same day the article was finished.

One thing is missing from both readable ones. As of 26 August 2026, neither lemon.io’s part-time hire page nor ncube’s on-demand hiring guide states a minimum monthly commitment on the page itself. The minimums, where they exist, live in the conversation rather than on the page, which means the first thing to ask any seller is the number of hours and the number of months you are actually agreeing to.

The demand side is just as visible. On 20 August 2026 somebody was advertising publicly for a developer to do ongoing feature work on a small SaaS. The arrangement is real and it is being bought. The open question is whether it is the right first purchase for an app no developer has read.

Buy the first month the way you would buy the first job

Start with one named thing rather than a trial month or a block of hours to be spent against a list nobody has written yet. One thing that is currently wrong or currently missing, described in plain words you and the developer both agree on, with the app working differently at the end in a way you can see for yourself.

Getting the last unfinished pieces of a half-built app over the line is one job with an end written into it, which is a different thing to buy than a month of somebody’s time.

Two useful things happen when you buy that way. The developer reads enough of the app to price the next thing without guessing, which is the only way a monthly number stops being a stab in the dark. And you find out how they work while your money is still attached to something visible. If it goes badly you have lost one job. If it goes well, the conversation about a month starts from evidence on both sides.

Have the accounts conversation at the same time, before anything recurring starts. Hosting, the domain, the database, the builder tool account, the app store listings: they stay in your business’s name, with the developer invited in. What to give a developer taking over your app covers what to prepare once you have chosen somebody.

For completeness, here is what AxonBuild does, since it is the same shape argued for above. The 20-minute video call with Bilal is free: show him the app and the one thing that is wrong or missing. If you want him to make the change, he checks the code and gives you a fixed quote, you agree what the app should do, and you pay after you see it working. Further features, releases and fixes can follow, each quoted the same way. There is no monthly arrangement on offer here, and no document comes out of the free call.

Common questions about ongoing developer support

What does ongoing developer support actually include?

Four things: somebody available when the app breaks, hours worked against your list of changes, the maintenance that arrives on other companies’ schedules, and a person who already knows your codebase well enough to price a change quickly. What it does not include, unless it is written down separately, is monitoring, a guaranteed response time, or any named result by any named date.

Do I need a developer every month if nothing is broken?

No, and this is the most common overspend for a one-app founder. If the app is stable, the change list is short, and no user’s day breaks when it goes down, there is no recurring work to buy. What is still true is that the store, the runtime and the dependency alerts keep moving underneath you, so plan a check every few months rather than paying somebody to be available for it continuously.

How do I find someone to support my app?

Three routes, in rough order of how much work they push onto you. Marketplaces such as Upwork, Fiverr and Toptal, where you filter and interview yourself. Specialist part-time services such as Lemon.io, which match candidates for you and charge a premium for it. And agencies or outsourcing vendors, which sell teams rather than people. For one working app, an independent developer found through a referral or a marketplace is the usual answer.

How much does ongoing developer support cost?

There is no single answer, because the shapes are priced completely differently: an hourly part-time arrangement, a monthly agreement with an agreed number of hours, and a per-job price all produce different totals for the same work. The bands themselves, what a marketplace freelancer, an independent developer and a firm each charge for an app that already exists, are set out in full on what different kinds of seller charge for an app that already exists. AxonBuild does not sell a monthly arrangement: each change is quoted after Bilal has checked the code, and further changes can follow the first.

Is a part time developer enough for one app?

For most one-app founders, yes, and often more than enough. A single AI-built app with a few hundred users generates a handful of hours of genuine work in a normal month, most of it dependency updates and small changes. The two situations that outgrow a part-time arrangement are an app changing every week because the product is still moving, and an app where an outage costs real money at unpredictable hours.

What happens to my app if nobody maintains it?

It keeps working, right up until something outside it moves. The three published schedules that move on their own, for the apps they apply to, are the app store target API floor, which cuts your reach to new users on newer devices when you fall under it, the runtime going end of life, after which critical fixes stop arriving for that version, and dependency alerts, which accumulate unhandled. None of these breaks the app the day they happen, which is exactly why they get ignored until they do.

Can the builder tool keep doing the work instead of a person?

Partly, and less than the marketing suggests. Builder tools are good at adding features to code they generated and poor at the maintenance work in this article, because that work is about versions, platform requirements and dependency graphs rather than about product changes. Automated dependency updates are the clearest example: GitHub’s own documentation says the alert closes when somebody merges the pull request, and that some deeper dependencies cannot be updated automatically at all.

Who can help me with my app when I am not a developer?

Anybody you hire needs to be able to explain what they did in words you can check, which is the real filter rather than any credential. In practice that means asking for the change to be shown working rather than described, keeping the accounts in your own name so no single person can lock you out, and starting with one small job so a bad fit costs you one invoice. Not being able to read code is normal for the owner of an AI-built app.

Should I pay for availability or pay for each job?

Pay for each job until the jobs stop having ends. Paying for availability becomes cheaper when you are buying so many small jobs that the negotiating and re-explaining costs more than the work, or when the value is somebody answering quickly rather than producing a specific thing. Until one of those is true, per job keeps the risk on the seller and the money attached to something you can see.