Questions people actually ask.

It depends on what the system has to do, which is an unsatisfying answer, so here is the ladder we actually use. These are the same ranges as the budget field on the contact form.

Every engagement is quoted in writing after we have watched the current process. You get a fixed scope with phases, what each phase costs, and what is explicitly out of scope. If we think your problem sits below the bottom of that ladder, we will tell you that rather than pad it.

A website is usually one to two weeks. A focused tool is four to eight weeks. One product implemented properly is two to four months. Anything connecting several systems runs longer, and we phase it so you get something working early rather than waiting for everything.

The honest variable is not our build speed. It is how quickly decisions get made on your side and how clean your existing data turns out to be. Both are worth knowing before we start, which is why scoping comes first.

Yes, and it is normally the right way to scope. A fixed date forces the conversation about what actually has to work on day one versus what can follow in a second phase.

What we will not do is agree to a date we do not believe in. If the scope will not fit the calendar, we will say so while there is still time to cut something.

Yes, and it is written into the engagement rather than offered as a favour later. You own the source code, the database, the hosting accounts, the domain, the documentation, and the operational knowledge.

There is no licence to keep paying to use what you commissioned, and nothing in the build depends on a platform only we can access.

The fair question, and the reason ownership above is written the way it is.

Three things reduce that risk deliberately. The code is boring on purpose — plain PHP and MySQL, standard hosting, no unusual framework — so any competent developer can pick it up. Written documentation covering how it works, how to run it, and how to change it is delivered as part of the project, not sold separately afterwards. And you hold every account and credential from day one.

If we disappeared tomorrow, you would be inconvenienced. You would not be stranded, and you would not be starting over.

Often, yes. We will read what exists before quoting, because sometimes the honest answer is that repairing it costs more than replacing it, and you should hear that before you spend money either way.

What makes a takeover straightforward is access: the source, the database, and the hosting. What makes it hard is a platform that will not let you export your own data.

Systems run on standard hosting you control. We can manage it or hand it over entirely; either way the accounts are in your name.

Support continues past launch, with the same people who built the system. Launch is when real use starts and the first genuine problems surface, so it is the wrong moment for a handover to strangers.

No. Most people do not, and arriving with a written specification is often worse than arriving with the spreadsheet.

Show us what the team does today, where information gets lost, and what takes too much time. A screen recording of someone doing the job is more useful than a requirements document, and it takes two minutes.

Usually, and often that is the cheaper answer. Plenty of engagements need nothing new built — the systems exist and simply do not speak to each other, so a person has become the integration.

If your accounting, point of sale, or property management system is working, we would rather connect it than replace it.

Yes. Local processing matters here, and we build against whatever you already bank with rather than forcing a switch to something that assumes a mainland merchant account.

That is the actual test, and it is why we watch the current process before designing anything. A system that is technically correct and operationally unusable has failed.

Interfaces are built for the conditions the work happens in: one hand free, a phone, a weak signal, a queue forming. Training and written documentation come with the build.

It is part of the design conversation from the beginning, not something discovered in September.

That means backups you can actually restore from, sensible behaviour when connectivity drops, data held somewhere that is not only on this rock, and a plan for the week after a storm when everyone is working from a phone.

Yes, across the Caribbean. The conditions we design around — multi-island logistics, local payment rails, bandwidth that varies, small teams, storm season — are regional rather than territorial.

Being based in St. Thomas means the same time zone and no need to explain any of it from scratch.

Ask it. Email hello@fruitstack.vi or use the contact form — you do not need to have your project figured out to start a conversation.