IntrApp covers what a small or medium company does day to day. If you need something that is not in there, that is not a dead end, and a few minutes from now you will be able to guess which side of the line your request falls on.
Specialist software is deep, and most of that depth is never used by most of the people who have it. A system is not good because it knows everything about one thing, it is good because the work as a whole is visible in it. That is why we go for breadth, and why we do not try to guess in advance what is missing at your company. You know that, we do not.
The sentence most purchases die on
"It looks good, but we need X, and you do not have it." At that point most suppliers give one of two answers. One is that they will add it to the roadmap, which usually means never. The other is that it will be twenty developer hours. Neither answers the question.
What we do instead
We look at how many other people would benefit. If roughly three quarters of our customers would use it too, we build it for free, it goes into the shared system, and everyone gets it, not only the customer who asked. You do not pay for what is good for everybody.
Why this is worth it to us
Because a broadly useful feature adds value for every customer, so the product improves rather than one request getting closed. That is the only reason this offer is sustainable, and it is better to write it down than to let it look like generosity.
The limit
Where this offer stops
An unlimited promise is a suspicious one, so here are its two limits. Whether a request is broadly useful is our call, because we are the ones who see the whole customer base and you see your own. That is not about authority, it is the only vantage point from which the question can be answered at all. The other limit is that we are not promising immediate delivery. What we promise is that a broadly useful request enters development instead of being quoted as custom work. If you need a date, let us discuss it up front rather than afterwards.
Which side
You can usually tell in advance which way a request will go
There is no exact formula, but the pattern is clear enough that you can guess it yourself.
This usually goes into the shared system
A field you need that would not bother anyone else. A filter or a view you happen to be the first to miss. A notification that has not been firing. A list that ought to be exportable. A permission setting that currently hands out access in chunks that are too big. When these get built, other customers start using them too.
This usually stays custom
Your own calculation logic that nobody else does the same way. An external system only you work with. An internal policy modelled exactly, with your steps and your names for them. An industry rule that does not apply to our other customers. There is nothing wrong with any of it, it just does not belong in the shared system.
This sits between the two
Most real requests land here, and the wording decides it. If you write "this is what we call the steps here", that is custom. If you write "I cannot see in one place what got stuck this week", that is probably everyone's problem. It is worth describing the problem rather than the solution you have already designed for it.
The process
What happens after you send it
There is no assessment fee, and no step where we ask you for something just to be able to tell you what it costs.
You describe what is missing
A paragraph or two is enough. The most useful thing you can write is what does not work today. What has to be copied across by hand, what you always look for twice, what you only find out about once it is too late. You do not have to design the solution, that part is ours.
We look at who else it affects
This is the step nobody outside can do, which is exactly why the call is ours. If the same thing has come up elsewhere, that is a strong signal. We write back and tell you which branch it is on, shared or custom. That answer is the reason to write in the first place.
If it is shared, it enters development
At no charge, and it does not appear only at your company but at every customer. At that point you are not a customer but a co-developer, because your request shapes the product. In exchange the ordering is ours, because other customers' needs weigh in too, and it is better to know that in advance.
What makes a description usable
"We need a report" is not enough, because it does not say what you want to learn from it. "At the start of every month I spend half a day working out how much time went on which project, and something is always left out" is precise. To the first we can only reply with a question; to the second we can reply with an answer.
If it is custom, we talk about it
Only then does money come into it, and even then up front and specifically. Custom work is billed at our specialist hourly rate. No framework agreement, no annual commitment, and no charge for us simply to look at the request.
If IntrApp is not the right answer, we will say so
That happens too, and it is better to know in advance that it does. When it does, we say why. Either the requirement really is specific to you, in which case the custom branch is where it belongs, or what you are asking for is essentially another system, and that is cheaper to hear now than in six months.
What we will not do is leave you waiting. An unkept promise to add something to the list costs both of us more than a clear no, because after a clear no you can decide, and after the other you can only wait. The same goes for the product itself. If you are looking for the deepest possible tool in one area, you will find better than us, and that is how it should be. That is not a shortcoming, it is a decision.
Built together
The domain knowledge is yours, the engineering is ours
An industry-specific requirement is not an obstacle, because we do not have to become experts in your field. You know what the regulation requires, how your trade calculates, what the real order of the steps is and where it tends to fall apart. We know how that becomes a system that still runs tomorrow, keeps receiving updates, and does not break on the first exception. The two work together, neither works alone.
You bring the requirement
We are not asking for a specification, we are asking for how you work today. Which step follows which, who approves what, when paper is needed, and the three exceptions everyone knows by heart but nobody has written down. That is the knowledge nobody can guess from the outside, and the reason an external assessment usually takes months and costs a lot of money.
We bring the engineering
Permissions, audit logging, file handling, notifications and customer records are already there, so we do not start at the foundations but where your operation genuinely differs. The question is not whether we can build it, but where it belongs inside the system.
Small steps, in production
The first version is the narrowest working one your team can already use, because the real gaps show up after the first week, not on the drawing board. We wrote more about this in our article on LEAN and MVP.
Why the custom branch is not a dead end
Classic bespoke development ends with your system frozen on the version it was built against, and three years later nobody dares touch it. Here the custom part lives on its own branch and keeps receiving the shared updates, so you do not fall behind the product. A custom feature is not something you buy by giving up everything that comes later.
Write down what is missing
We do not ask for company details, we do not call you, and there is no assessment fee. A paragraph or two about what does not work today is plenty to get an answer.
The cookies needed to run the site are always on. Statistics and marketing cookies only with your consent, and you can change your mind at any time under Cookie settings in the footer.
Privacy policy