Project Lead / Solo Software Engineer / C# & Avalonia

I turn game-studio problems into focused desktop products.

I’m Sean Murray, the Project Lead and sole developer of an independent game development studio. I plan, design, build, test, and document C# desktop applications with Avalonia.

My work sits between software engineering and technical product ownership: defining a useful problem, reducing it to a workable release, and making the implementation explainable.

Read the project files ↓ sean.murray1997@hotmail.com ↗

01 / Selected work

Project files

Three C# and Avalonia desktop applications showing collaboration, decision-support, accessibility, product thinking, and end-to-end technical ownership.

Find

A cross-platform desktop overlay for shared pointing, drawing, highlighting, and visual explanation across a live session.

The problem: Screen sharing gives one person control and everyone else a voice. Pointing precisely at a changing interface is still awkward.
My role: Project Lead and solo software engineer responsible for product scope, C# implementation, Avalonia interface design, testing, and technical decision-making.
Engineering focus: Local-first rendering, vector-stroke ownership, reconnect recovery, event ordering, and snapshot synchronisation.
Evidence to publish: Illustrative evaluation: three concurrent clients, simulated delay, a 500-stroke snapshot, and a five-second reconnect test.

Key implementation decision

Transmit vector points rather than screenshots. This keeps the event stream inspectable and makes local interpolation possible.

An explainable desktop drafting tool that compares player, champion, role, patch, composition, and risk factors.

The problem: Drafts happen quickly, but the information behind a good choice is scattered across statistics, memory, and player preference.
My role: Project Lead and solo software engineer responsible for the scoring concept, data structures, C# implementation, Avalonia interface, and product workflow.
Engineering focus: Avoiding false precision. A score needs to explain its inputs and uncertainty instead of pretending to be an objective truth.
Evidence to publish: Illustrative evaluation: twelve repeatable draft scenarios, six visible score components, weight-sensitivity checks, and incomplete-profile warnings.

Key implementation decision

Keep component scores visible. Coaches should be able to reject the recommendation without reverse-engineering a black box.

A user-controlled speech workflow that records, transcribes, reviews, structures, and exports spoken ideas.

The problem: Conventional transcription captures words but leaves the user to restructure, correct, and move the result elsewhere.
My role: Project Lead and solo software engineer responsible for the recording workflow, C# implementation, Avalonia interface, accessibility, testing, and export design.
Engineering focus: Keeping automation useful without silently changing meaning, especially for names, commands, and technical vocabulary.
Evidence to publish: Illustrative evaluation: ten sample recordings, two interchangeable providers, a keyboard-only workflow, and interrupted-processing recovery.

Key implementation decision

Preserve the raw transcript beside transformed output. The user should always be able to see what the system actually heard.

02 / Working record

One-person studio, full project ownership

My current experience comes from leading an independent game development studio and taking software from initial problem through architecture, interface, testing, documentation, and iteration.

Current

Independent studio

Project Lead & Solo Software Engineer

Independent Game Development Studio

Set project direction, define the smallest useful release, and convert broad product ideas into implementable work.
Build cross-platform desktop applications in C# and Avalonia, covering interface code, application state, services, and data.
Own testing, debugging, documentation, prioritisation, and the technical trade-offs normally distributed across a small team.

Selected portfolio

C# desktop product development

Three Applied Software Proofs of Concept

Collaboration, game-team decision support, and speech productivity

Designed a collaborative annotation system around shared state, participant ownership, reconnect behaviour, and local-first input.
Modelled an explainable drafting assistant that keeps component scores, uncertainty, and user-specific data visible.
Structured a transcription workflow around source preservation, correction, accessibility, provider abstraction, and export.

Ongoing practice

Technical leadership

Solo Studio Operations & Engineering Direction

Planning, implementation, review, and iteration

Maintain project roadmaps and choose work according to user value, engineering risk, and the cost of supporting each feature.
Document architecture and decisions so projects remain reviewable even when development pauses or priorities change.
Use small proofs of concept to test uncertain workflows before committing to a larger implementation.

03 / Profile

How I approach the work

Working alone has made me comfortable moving between product decisions and implementation details. I can define a workflow, build the interface, model the state, investigate failures, and explain why the system works the way it does.

I am interested in software engineering, game-tools, desktop application, and technical product roles where C# expertise, practical ownership, and clear engineering judgement are useful.

Own the whole loop

A feature is not complete when the code compiles. It also needs a clear purpose, understandable states, testing, and a supportable path.

Keep decisions explainable

Architecture, scoring, and automation should expose their assumptions so another engineer or user can challenge them.

Design for failure

Slow networks, incomplete data, interrupted processing, and invalid input are normal product states-not edge cases to hide.

Core language

C# · .NET 10 · asynchronous programming · object-oriented design

Desktop interface

Avalonia · XAML · MVVM · commands · bindings · custom controls

Application design

State management · service abstractions · local-first workflows · failure states

Data & integration

SQLite · JSON · SignalR · provider interfaces · local persistence

Project delivery

Git · debugging · testing · documentation · prioritisation · technical leadership

04 / Contact

Have a difficult product problem?
Send the unpolished version.

I’m interested in software engineering, game-tools, desktop application, and technical product roles where I can take responsibility for both the implementation and the decisions around it.

Email ↗ GitHub ↗ LinkedIn ↗ Résumé pending

I turn game-studio problems into focused desktop products.

Project Lead & Solo Software Engineer

Three Applied Software Proofs of Concept

Solo Studio Operations & Engineering Direction

Own the whole loop

Keep decisions explainable

Design for failure

Have a difficult product problem? Send the unpolished version.

Have a difficult product problem?
Send the unpolished version.