Q&A

The questions that come up in almost every first call.

How do I get started?

Short kickoff call. I'll explain my background, you describe your system and the problems you're solving, and I ask questions until the picture is clear.

After that, I assess whether I can add value and what exactly you'll get. You decide if it's worth it.

If yes, we define the way forward: what we do, in which phases, what the deliverables are, and what it costs.

Do you work on-site or remote?

Both.

On-site when I need to understand the system and workflows. Development and architecture are usually remote.

I adapt the way of working to what the project really needs.

Can I work alongside my existing team?

Yes. Actually, that's one of the ways of working I prefer.

I'm not here to replace you, but to work with you — understand the system, solve complex problems, make architectural decisions, and transfer knowledge as we work.

How long does a .NET Framework migration usually take?

There's no single answer that fits every system.

Usually, writing code and tests is not the hardest part. The real challenge is doing it gradually without damaging the existing system or introducing unnecessary risk to production.

That's why I prefer to first understand the system, identify the dependencies and risks, and only then give a real estimate.

Can the system stay live during migration?

Yes. That's usually the goal.

I plan the migration in phases so your existing system keeps working while the new parts come in gradually.

The focus is not just on the code compiling, but on the system continuing to work properly in production.

What if the diagnosis says it's not worth doing the project?

That's also a good outcome of a diagnosis.

My goal is not to start a project at any price, but to understand what's really needed, what the risk is, and what it costs.

If the conclusion is that it's not right to do the project now, or if the cost doesn't justify the benefit, I'll tell you that.

Do you sign an NDA?

Yes.

I'm used to working with systems, code, and sensitive business information, so confidentiality is a natural part of the working process.

Who owns the code and documents you produce?

Code and documents created as part of the project belong to you.

General-purpose code, tools, and libraries I've built that don't include your information or intellectual property stay with me and can be used in other projects too.

Is my data sent to an AI model?

Not necessarily.

AI is a working tool, not a requirement in itself.

When there's value in using a model, I assess what information really needs to go to it and in what environment. In cases where the information is sensitive, we can work with secured models and environments, including local solutions, depending on project requirements.

What happens after the project ends?

No lock-in.

I do a clean handoff of the code, documentation, and knowledge needed so your team can continue working independently.

If you want, we can continue with ongoing support — but that's your choice, not a condition for finishing the work.

Do you take small jobs?

Yes.

Not every problem needs a months-long project.

If you need a few hours of consulting, an architecture review, a POC, a solution to a specific problem, or help with a technology decision — we can start there.

What tech do you work with?

Core: C# and .NET.

Also: TypeScript, JavaScript, Angular, React, Docker, Kubernetes, and other technologies as needed.

For natural languages — I work in Hebrew and English, including ongoing work with teams, clients, and technical documentation.

I don't start with technology. First we understand the problem, then we pick the tools that fit it.