About

I have spent most of my career in financial technology and tax software. That work teaches a specific set of habits. You learn to read the specification before you write the code, to treat a rounding difference as a defect, and to assume that someone will reconcile your output against a source of truth and ask you why the two disagree.

Those habits carry into everything else I build. AI systems need the same treatment, because a model that is right most of the time is a liability anywhere a wrong answer is expensive. Games need it too, in their own way. A player notices the frame that dropped, the input that did not register, and the bug that only appears in hour nine.

Why the company exists

Software work is often sold by the seat. A larger team is quoted because it looks safer, then the same three people do the work and the rest of the invoice covers coordination. Luc Interactive is deliberately one person. You talk to the engineer who writes the code, the decisions are made in the open, and nothing gets lost between a sales call and a delivery team.

How I work

• Written scope before code. If it is not in the plan, it is a change, and we talk about it.
• Short milestones. You should be able to run something early and often.
• Tests around anything that touches money, tax, or data you cannot afford to lose.
• No dependency on me that you cannot unwind. You get the repositories, the deployment path, and the documentation.
• Plain answers. If your idea will not work, you will hear that from me before you spend money on it.

Where I am

Based in the United States, working with clients remotely. I overlap with European mornings and with the full United States workday, and I keep a predictable window for calls so scheduling is not a project of its own.