A guide to hiring a Silverlight developer
Silverlight is a Microsoft framework that let companies build rich, app-like screens inside a web browser. Microsoft has ended support for it and current browsers do not run it, but some businesses still rely on an app built this way, often for a task that staff do every day. Hiring for Silverlight today is mostly about care and rescue: keeping the app steady and finding a safe way to replace it. Here is what the work includes, how to judge a candidate and how to work with a remote engineer. It is written for owners and team leads who inherited an old app and need a clear next step.
What a Silverlight developer works on
Silverlight apps were written in C#, with screens described in XAML. They usually talk to a server for data, often through services built with older Microsoft tools. A Silverlight developer can read all three layers: the screens, the logic and the services. That is what makes them useful now. They can tell you what the app does, which parts are fragile and what would be lost if the app stopped working.
Where the roles differ
A WinForms developer or a Prism developer builds Windows desktop apps and shares a lot of the C# and XAML knowledge. An Angular developer or a React developer builds modern web screens. A Silverlight developer sits between them: the person who understands the old app well enough to guide the move to either side. Many projects use a Silverlight developer with a web developer for the new build.
When a Silverlight developer makes sense
- Your business still uses a Silverlight app and the people who built it have left.
- Staff can only open the app with a special setup, and you want to remove that need.
- You plan to replace the app and want its rules written down before you start.
- A fault keeps returning and nobody can find the cause in the code.
- You are buying or merging with a company that runs a Silverlight tool.
If the app is not used any more, you may not need a developer at all. A short review can confirm that, and it is better to find out before spending on a rebuild.
Start with a review
Before any rebuild, ask the developer to review the app. A good review lists the screens, the main tasks users perform, the services in use and the places where data enters and leaves. It also names the risky parts. This document becomes the plan for the move, and it is useful even if you later change developers.
Choosing the new home
Most apps move to the web or to Windows desktop. The web suits teams that work from many places. Desktop suits offices that need local files, printers or devices. A developer who has done both can show you the trade-offs in plain words. Avoid anyone who recommends a rebuild before reading the code, or who promises a quick, simple move.
Interview questions to try
- How would you find out which features of an old app are still used?
- Where do business rules usually hide in a Silverlight app?
- How would you move a few screens at a time without stopping users?
- How do you check that the new app gives the same results as the old one?
- What would you write down before leaving the project?
Listen for calm, practical answers with real examples. Doubt anyone who treats the job as a simple copy.
Try a paid mini project
Give each finalist one small piece of real work, for example reviewing one screen and its service calls, or fixing a known fault. Pay for the hours. Then judge how clearly the person explains what they found, what questions they ask and how careful they are with your data.
Plan the access carefully
Old apps often connect to databases that hold customer or staff records. Give your developer only the access the job needs, use accounts owned by your company and keep a copy of the code in a repository you control. Remove access the same day the work ends.
Working with your team
Bring in the people who use the app every day. They know which screens matter and which workarounds exist. A weekly call and a shared task list keep people in step, and a written note after each change helps whoever opens the code next.
Set a sensible timeline
Moves away from old apps rarely go to plan on the first try. Ask the developer to split the work into small stages, each with a clear result you can check, such as one working screen or one matched report. Short stages let you stop, change direction or pause when budgets change, and they give your staff time to test each part before relying on it.
Mistakes to avoid
- Waiting for the app to fail before making a plan.
- Rewriting every screen when only some are used.
- Skipping data checks when the new app goes live.
- Letting one person hold all the knowledge of the old code.
Want to see related roles? Our WinForms developers build Windows desktop apps, and our Angular developers build modern web apps.