The things you would ask on the second call.

RayneBowTech is new, and you should hear that from me rather than work it out later. The work is not new — the systems engineering behind it is what I do. What being early means for you, practically, is that I take on very few clients, you deal with me directly rather than an account manager, and the first engagements are priced to reflect that you are taking a chance on someone whose website does not yet have a wall of logos on it.

Not yet, and I am not going to show you an invented one. What I can do is share my screen and walk you through the operations system I run my own business on — live, with the parts that are held together with tape pointed out honestly. That plus an hour of conversation will tell you more about whether I can do this than a polished case study would.

If proof matters more to you than price, wait six months and check back. That is a legitimate decision and I will not try to talk you out of it.

I hold a day role and run a deliberately small number of client projects alongside it. That is exactly why I take one build at a time, and why the dates I quote are realistic rather than optimistic.

You get a schedule I can actually hold to, a written update every Friday whether or not there is good news, and an honest no if the timeline you need is not one I can meet.

It is the real risk of hiring one person instead of a firm. Three things reduce it:

• Everything is built on standard, boring, well-documented technology. There is nothing proprietary and no black box only I can open.
• The code and documentation live in your repository, on your accounts, from the first day — not mine.
• Payment is tied to milestones you can see working, so you are never far ahead of what you have actually received.

Handover documentation is a deliverable, not an afterthought. It is written so that someone who has never seen the system can run it.

Only what you have said it can, and by default the answer is no. There are four levels, and you choose which one you are buying:

• Level 1 — Observe. It reads and shows you. Dashboards, status boards, alerts. It tells a person; the person decides.
• Level 2 — Capture. It collects information correctly the first time, with someone at the keyboard.
• Level 3 — Draft. It does the work and puts it in front of a person to release. The invoice is already typed and waiting. Nothing leaves the building without a human action. This is the default, and it is where most of the value is.
• Level 4 — Act. It sends, spends and posts on its own. Available, but never by accident — it needs a written authorisation listing every action and its limits, a soak period where it drafts first so we both see its real error rate, provider-level spend ceilings, and a kill switch anyone in your office can use.

Plenty of people get to the end of a Level 4 soak period, notice the drafting version already gave them their hours back, and stay at Level 3. That is a good outcome, and I will tell you so.

The four levels in more detail.

It will, eventually. So the design assumption is that it is wrong, not that it is right. Three layers:

• Nothing irreversible runs unsupervised. Anything that reaches a customer, moves money or deletes data passes through an approval step or a hard limit that you set. The autonomous parts are the parts where being wrong is cheap and fixable.
• Everything is logged and reversible. Every automated action records what it did and why, and there is a way to undo it.
• There is a kill switch. One control stops the automation and returns the process to manual. Your team is trained on it before go-live, and at least two of your people know where it is.

Which actions need approval and which do not is your decision, agreed in writing before anything is built — and at Levels 1 to 3 the answer is that nothing reaches the outside world without a person, structurally, rather than as a setting someone could change.

No. Work runs on enterprise API tiers whose terms state that business inputs and outputs are not used to train the provider's models. The specific providers and the relevant clauses are named in your proposal, so whoever needs to verify that can verify it.

If you have a data classification policy, send it over before we scope and the architecture will be designed to it rather than retrofitted.

Some of it, and you will be told exactly which fields. Three limits apply by default: only the minimum necessary data is sent, identifiers are stripped where the task does not need them, and anything genuinely sensitive can be processed by a model running inside your own environment instead.

Your proposal lists every external service the system touches and what goes to each one. No surprises, and nothing you have to discover.

Model usage is metered and billed to your provider account, not marked up through me — I would rather you saw the real number. For a typical build it runs in the tens of dollars a month rather than the thousands, and it is estimated with a range in your proposal.

A hard spending cap is built in, enforced at the provider rather than only in code, with an alert well before the ceiling. The first month's actual figure goes in your handover report, so you end up with the truth rather than my estimate.

For some of it, honestly yes — and if that is the right answer I will tell you and save you the money. A chat tool is excellent at helping a person do a task faster.

What it cannot do is run at two in the morning with nobody there, read from your CRM and write to your invoicing system, retry when a sync fails, and leave a record of having done it. The value is not the model. It is the plumbing around it, and the fact that it runs whether or not anyone remembers.

Tell me which regime and I will tell you honestly whether I can meet it. Regulated work changes the architecture, the subprocessor agreements and the price — it is doable, but never as an afterthought bolted on at the end.

If your compliance burden is heavier than what I can properly support, you will hear that in the first conversation rather than discover it during an audit.

You do. On final payment, all of it — code, data and documentation — transfers to you outright, and it has been living in your repository and on your accounts the whole time anyway.

I retain only the right to describe the work generally, and even that is yours to decline. It is written into the agreement rather than left to goodwill.

They do, and a free assessment is a sales document — it exists to justify the largest project the person can sell you. It is not written to be useful on its own.

The audit is a deliverable you own. It is written so that you could genuinely hand it to a different developer or take it in-house, and it includes a section on exactly what someone else would need to know to build it. That is only possible because you paid for it.

And the fee comes off the build price if you go ahead within sixty days, so if you do build with me it is effectively free.

The milestones are arranged so you find out early rather than late. There is a working demo on your real data at the halfway point, before the second payment is due. If what you see is not what you wanted, we fix it then — or you stop, and you have paid only for what you have received.

Nobody is asked to pay for the whole thing on faith.

No. It runs 40% on signature, 30% at the mid-build demo, 30% at handover, on net-15 invoices. That is standard for custom development, and it is what makes sure I am never in a position where I need to cut corners in order to get paid.

You ask, and you get a price and a revised date, and then you decide. Changes are quoted in writing as a change order and agreed before any work on them starts.

What will never happen is something appearing on an invoice that was not agreed first.

That is the part most builds get wrong, so adoption is treated as part of the deliverable rather than your problem after handover. Training happens on your real work, not on demo data. Where possible the system is built into tools your team already opens, rather than adding another login to their morning.

If your team hates it, it does not matter that it works.

No. The discount is for taking a chance on someone early, and it stands regardless of what you end up thinking. You approve anything published before it goes out, you can decline the case study entirely at handover, and the price does not change if you do.

A testimonial that was bought is worth nothing to either of us.