About BoringJob

Hi, I'm Dzmitry. I'm the engineer behind BoringJob.

For 11 years I have been building and fixing the software businesses depend on: Excel workbooks with years of macros inside, desktop apps nobody wants to touch, databases behind a dozen reports, and the integrations between them.

BoringJob is how I offer this work directly, with no account managers and no agency in between. I read your message, I reply, and if we work together, I do the work.

Dzmitry Kazhamiakin, founder of BoringJob
Dzmitry KazhamiakinFounder and software engineer
Experience
11 years in software development
Based in
Poland (EU)
Works
Remotely, with clients in any country
Languages
English, Polish, Russian

Why "BoringJob"?

Because boring jobs are where time and money leak away: the weekly report, the double data entry, the fragile macro, the app that only one PC can still build.

They're often too small for an agency and too annoying to keep doing by hand. I like them. There's usually an interesting puzzle underneath, and solving it properly makes someone's week much easier.

What I work with

Desktop and business software

  • C#
  • .NET Framework and modern .NET
  • WPF
  • Windows desktop applications
  • Internal business tools

Excel and Office

  • Excel
  • VBA
  • VSTO add-ins
  • Office automation

Data

  • SQL Server
  • Data processing
  • Migrations
  • Reconciliation
  • Reporting

Integration

  • APIs
  • File-based interfaces
  • System-to-system data flows

Legacy systems

  • Maintenance
  • Debugging
  • Stabilization
  • Step-by-step modernization

Product engineering

  • iOS
  • Flutter
  • Practical AI-assisted development

How I work

  1. Understand first

    I want to see how the work is done today, workarounds included. That's where the real requirements are.

  2. The smallest change that lasts

    I improve what exists when that's enough, and rebuild only when a small fix would cost more in the long run.

  3. Boring technology, on purpose

    Proven tools that your team or the next developer can maintain.

  4. Visible progress

    Small steps you can check on real examples, not a big reveal at the end.

  5. A proper handover

    Notes, a walkthrough, and code another developer can follow.

Independent products

I also design, build and publish my own apps. They're independent products, not client projects. They show that I can take software from idea to release and keep it running.

Got a boring problem worth fixing?

Describe it in plain words. I'll read it and reply myself.

Describe your problem