Solfreaks AppVentures is how we work with people who have the idea, the audience or the brand but would rather share the risk than pay a full development fee. We co-build, run or grow apps with a partner, and we're paid out of what the app earns, partly or entirely, instead of by a normal invoice.
We say no to most of what we're offered. This page explains why, so you can tell quickly if your idea has a chance before you spend an afternoon pitching it.
Kinds of deals we do
- Build for a share. We build the app at a reduced fee, or with no fee, and take a share of its revenue for an agreed period or for good.
- Take over and grow. You have an app that has stalled. We repair it, as in our legacy app revamp work, then grow it, and our share applies to the growth we create.
- Joint products. A new app owned together, sometimes through a new company, where both sides put in work and cost.
- Store release and running. We publish, update and support the app, with developer accounts and ownership set out in the agreement.
- Revenue from the start. The app is designed around its earnings, with ads, subscriptions or purchases planned as part of monetisation setup before launch.
- An open ledger. Revenue, costs and decisions go into a shared sheet or dashboard that both sides can see at any time.
- A written agreement. It covers ownership, the revenue split and what happens if one side walks away. You should have your own lawyer read it, because we're developers, not a law firm.
What each side brings
A partner usually brings one or more of these: an audience, a distribution channel, knowledge of a niche, a brand people trust, an existing app with users, or a marketing budget. Time matters too. A partner who can't answer a question within a few days slows the project more than a modest budget does.
We bring design, development, testing, publishing and ongoing running of the app, and we take on part of the cost by working for less than our usual fee. Neither side should be carrying the other.
What we check before saying yes
- A first call. You describe the idea and what you bring. We usually reply within a few days.
- Market and fit check. We look at competing apps, store data and how you plan to reach users. This typically takes a couple of weeks.
- A small test. Often a landing page, a clickable prototype or a small paid test, before either of us commits to a full build.
- Term sheet. The revenue split, who decides what, who holds which account and the exit terms, written in plain language first and then by a lawyer.
- Build and launch. A focused first version typically takes a couple of months, depending on scope.
- Quarterly review. We look at the numbers together and decide to continue, change course or wind the app down.
Why most ideas get a no
We decline when an idea only works if huge numbers of strangers find the app on their own, when the partner brings no audience, no marketing budget and little time, and when the market is dominated by well-funded apps with nothing new to say. We also decline when the app depends on rules we can't meet, and when expectations are far from what an app of this kind usually earns. No one can promise that an app will earn anything, and we don't.
A partnership is probably not for you if you want to keep full ownership and simply buy development. A normal project is simpler then, such as a SaaS MVP or app build, and you owe us nothing afterwards. A partnership makes sense when both sides have something at stake.
Money, time and paperwork
There's no price list, because a partnership is a different kind of deal. The terms depend on how much of the build cost we absorb, what you contribute in budget, audience or brand, the running costs of the app, and how long the revenue share lasts. The shapes we offer are a revenue share with a reduced build fee, a revenue share with no build fee for a small app, a joint company, or a take-over deal where our share applies only to growth. If you want help afterwards with ongoing marketing, our growth retainer is a separate monthly arrangement.
The decision usually takes a few weeks, and a first working version a couple of months after that. The quote, or term sheet, follows a short discovery call, and the written agreement should be reviewed by a lawyer you choose.
Why partner with a small team
You talk directly to the people building your app, in a small Rawalpindi team with apps published on Google Play. Ownership of the code, the store accounts and the revenue is agreed in writing before work begins, and the money is tracked in the open. If you have an idea or an app that fits, bring us the idea or the app and expect a frank answer, including a no.
Open-source tools and references
A few public projects that come up a lot in this kind of work. They belong to other people and teams. We link to them because they are worth a look, not because anyone pays us to.
- android/nowinandroidGoogle's reference Android app built with Kotlin and Jetpack Compose.
Frequently asked questions
Do I pay anything upfront?
It depends on the deal. Sometimes there's a reduced fee, sometimes none. It's never nothing from your side, though, because we expect you to bring something concrete: an audience, a marketing budget, domain knowledge or your own time. A partner who contributes only the idea is usually not enough for us to say yes.
Who owns the app?
That is settled in the written agreement before any code is written. The common options are that you own the app and the accounts while we hold a revenue share, that we jointly own a company, or that ownership of the code and accounts is split by agreement. We won't start without it, and we suggest you have a lawyer check the wording.
How do you decide the revenue split?
There's no formula. We look at what each side brings, how much cost we absorb by working below our normal fee, who carries the running costs and how long the arrangement lasts. We show our reasoning in plain numbers, and we're open to negotiating, but we won't accept a split that makes the project unworkable for us.
What happens if the app doesn't earn anything?
Then we have both lost time, and we may have lost the fee we gave up as well. That's the reason we're selective and run a small test first. The agreement sets out how either side can stop, what happens to the code and the accounts, and what is owed, if anything.
Can I bring an existing app that already has users?
Yes, that is one of the clearest cases. We start with an audit of the code, store listing, analytics and revenue figures, which means we need read access to the store consoles and your analytics. If the app has a future, we agree a repair and growth plan, and a share that applies to the growth we create.
Talk it through with us
Tell us what you are building and where it hurts. You get a straight answer, a plan and a price, and if we are not the right people we will say so.
