Questions people ask. Answered plainly.

Do we own the code?

Your data does, always: the records, files, and content that make the application yours in any way that matters. The application itself runs inside Data Day's own environment and infrastructure, the same one every client's software runs in. That shared setup is what lets us build a working prototype for $500, when pricing every proof as a standalone project would cost far more.

If you want a standalone copy of the production code that runs on someone else's infrastructure, that's separate engineering work: pulling it out of our environment, replacing what it depends on, and documenting the handoff for whoever picks it up. We're glad to do it, and we quote it plainly when you want one, so the cost never gets baked into a build on the chance you might.

What happens to our data if we cancel or walk away?

It's always yours, handed over in a format somebody else can read, no matter which stage you're at or how you leave. On the prototype, letting it lapse means we take the hosted copy down and hold your data for ninety days, so coming back takes one email. On a live application, leaving means the same, plus the accounts, the domain, and a fair amount of time helping your next developer get oriented.

I don't have an idea. Is there anything here for me?

Yes, and it's the first thing on the pricing page. The retainer buys our time and you point it at whatever you like. No app, no project, nothing to launch. The spreadsheet that broke, the report you need by Thursday, the export nobody can open, the tool you're about to buy and can't evaluate.

A Working Session is $420 for two hours, with no retainer. Retainers start at $500 a month for four hours and a standing monthly call. You don't have to know what the problem is called. Describing it is enough.

What can I actually use retainer hours for?

Anything technical. Software, data, a website, a spreadsheet, a vendor, a device, an account nobody can get into, a decision you'd rather not make alone. We don't publish a list of exclusions because we don't keep one.

Unused hours roll forward one month, so a quiet stretch isn't wasted.

Why is the prototype a fixed $500?

Because it isn't the product. Its job is to let you try the idea so we can decide together whether it is worth owning. One fixed price beats an open-ended estimate when all you need is to find out.

The cost of owning it shows up in the production build: hardened for traffic, monitored, and scoped to what you need.

What does the whole thing cost, then?

Nothing, until we've agreed what to do. Talking it through is free, and so is filling out the online build form: we read what you sent, tell you what we'd build, and only then does anything get charged.

Three things have a published price. A prototype is $500. A Working Session is $420 for two hours. Retainers start at $500 a month for four hours, with a six month commitment.

Everything else is quoted to spec: the production build, the monthly cost to run it, card processing if it takes payments, and bigger retainers. You get the number in writing before any of it starts. A build can be paid once or spread across monthly payments.

For a sense of range, one of our live apps runs $5 a month. A full booking and front desk system for a spa costs more, and still saved that spa hundreds a month.

What will it cost each month once it's live?

One number, quoted with the production build. It covers hosting, the database, file storage, email and texting, backups, monitoring, and maintenance. Bug fixes are free.

We set it after the prototype has been live for thirty days, because by then we both know what it actually uses. If your usage changes a lot later, we requote before your bill changes.

If the application collects money, what does that cost?

A share of what runs through it, agreed in writing in your order before a card is ever taken. We don't publish one rate for it, because a checkout running a hundred small sales a day and one running four large invoices a month are not the same job and shouldn't carry the same number. Standard card processing comes out of our share, so nothing for it lands on your bill on top.

We handle the setup: the accounts, the verification, the processor, and the wiring. You don't open merchant accounts or read processor documentation.

Fees Apple or Google charge directly on purchases made inside their own stores, chargeback fees, and the extra cost of international cards and currency conversion pass through at cost. Nobody can absorb those.

It applies where our application is the thing taking the payment. If your customers pay through a system you run yourself, there's nothing passing through ours to share, and you just pay the monthly running cost in your order.

Can you take a share of the revenue instead of charging us?

Sometimes, yes. If what you have is a product that will make money, we'll consider taking on the build for a share of what it earns, or owning it with you outright, rather than billing you professional service rates. Most people who ask for this would simply rather do that than write checks for hours, and we'd rather have a reason to care how it does after it ships.

A partnership covers a new product only. It gives us no stake, claim, or interest of any kind in the business you already run.

There's no published price, because there's no standard arrangement. What each side puts in, how revenue is divided, who owns the code, what happens if either of us walks away, and what happens if it fails are settled in writing, in plain language, before either of us spends a day on it.

We can only carry a few of these at a time, so we say no to most of them. Being told no costs you nothing and doesn't change anything else you buy from us.

What if we need more than the retainer carries in one month?

We quote it before we start it, in writing, and you say yes or no. It never lands on an invoice you haven't already seen. Often the better answer is moving up a size for a month or two instead, and we'll say so when it is.

Unused hours roll forward one month, so a quiet stretch isn't wasted.

Does the retainer lock me into anything?

Standing retainers are purchased in 6 month commitments. A Working Session is one time and locks you into nothing. When a 6 month term is up it renews for another 6 unless either of us gives thirty days written notice before the renewal date. You can change size during a term on thirty days notice.

If you also have a live application with us, changing or cancelling a retainer doesn't touch it. Hosting, monitoring, backups, patching, maintenance, and free bug fixes carry on exactly as they did.

How does the twelve-month term work?

It applies to one thing: keeping a live application running. The prototype has no term; it is a thirty-day proof. Standing retainers carry a separate 6 month commitment.

The term starts the day your application goes live, which is later than the day you sign. Everything before go-live is month to month, so you can walk away mid-build on thirty days notice, owing only for work already done and the deposit terms in your build order.

The reason a term exists is that a live application is something people depend on, and the term is our commitment to keep it up for them.

When the term is up it renews automatically for another twelve months. There's no early termination fee, and no notice window you can miss, because thirty days written notice before the renewal date stops the next term from starting.

How do I know which retainer size is right?

Start with a Working Session if it's one problem, or the $500 monthly retainer if things keep coming up. If four hours a month isn't enough, we'll size something bigger with you.

Moving up or down takes an email and thirty days. Nobody's stuck on the wrong size, and unused hours roll forward so a quiet stretch isn't wasted.

What happens at the end of the thirty days?

Around day twenty we email with one question: do you want to own it? Answering is one button, and there's no sales pitch waiting on either answer.

Say yes and we quote the production build against what it needs, using the published cost drivers as the starting point. You get the monthly running cost with it. Say no and we take the hosted copy down, holding your data for ninety days, so coming back later takes one email.

Thirty days is deliberately short. A proof that sits around for a quarter has stopped being a proof and turned into free hosting.

What counts against my hours?

New behavior. A new screen, a new report, a new field, a new integration, a change to how something works. On a retainer with no application behind it, everything we do for you counts, which is the point of buying the time.

What never counts: fixing a bug, hosting, backups, patching, monitoring, maintenance, responding to you, or the meeting where we decide what to do. If it stops doing what it was built to do, that's on us and it's free. That holds on the prototype exactly as it does on a retainer.

Once it's live, how does a small app ever change?

A retainer, from $500 a month for four hours, or a Working Session at $420 when it's a one-off. Bigger changes get their own quote.

It sits alongside the running cost rather than replacing it, so the bill always separates what keeps the app alive from what makes it better. Bug fixes and maintenance are free either way and never touch those hours.

I already started building something. Can you look at it?

Yes. The free conversation is the place to start. Bring the repository, the export, or whatever you have, and we'll run it and read the code, then tell you where it stands: the parts that hold up and the parts that have to be rebuilt before customers or money touch it.

Often the wall is the same: a weak login, keys sitting in the browser, a database that lets a stranger read every row, nothing backed up. Sometimes an afternoon of help is enough, and we'll tell you that too.

Who can see our data?

Us, and only for doing the work you asked for. Your database runs on Supabase in a schema of its own, isolated by row-level security, so your records never mix with another client's. We don't share your data with anyone outside our team, and we don't use your idea to build a competing product of our own.

We'd like to show the work in our portfolio someday, but not until you tell us in writing that it's fine.

How do you handle the files we send you?

Uploads travel over an encrypted connection, get scanned for malware, and land in private storage nobody outside our team can reach. Ask us to delete them and we will, permanently.

As a practical matter, if a stand-in file would show us the same thing, send that instead of real records. It's the same advice we'd give anyone emailing anything sensitive around, and it costs you nothing to follow.