Windows development & engineering support from KomuraSoft

Technical Consulting & Design ReviewMake the key decisions before you build or change.

Unsure about a technology choice, architecture or existing component? We review the options against Windows-specific constraints and your workflow, then clarify what needs to be checked next.

No specification document needed. Start with what you know.

  • Work directly with an engineer
  • Start before requirements are finalized
  • Commission only the scope you need

You do not need a finished specification

Start with the problem you need to solve.

There are too many technologies and architectures to choose from

We compare them against your existing software, equipment, deployment environment and maintenance needs.

You are concerned about the design, but cannot pinpoint why

We examine the UI, communications, threads, resources and failure handling.

You need evidence to choose between changes and a rewrite

We explain benefits, effort and remaining uncertainties, then identify further investigation and priorities.

Discuss the technical details with the engineer doing the work.

Profile photo of Go Komura

Founder & engineer

Go Komura

A Windows-focused engineer works with you from the initial discussion through investigation, design and implementation. You do not need to have every technical detail worked out before getting in touch.

Experience & technologies / Company information

Published technical article

How to Handle ActiveX / OCX Today

Explore the technical considerations and design approach in this area. These explanatory articles are presented separately from commissioned project experience.

Read the technical article

Scope of support

A focused task or a complete application.

From a specific investigation or change to end-to-end development, we agree on a scope that fits your situation.

Technology selection and development strategy

Clarify goals, technical constraints and operating conditions, and assess implementation options and open questions.

Design review

Review the responsibilities of UI, communication and background processing, component interfaces and failure handling.

Modification and migration planning

Compare continued use, interface changes and replacement of existing assets, then establish priorities.

Examples of results and deliverables

  • Options and the reasoning behind a recommendation
  • Design risks and validation tasks
  • Review findings or an approach document within the agreed scope

These are examples, depending on the work commissioned. We agree on the scope and format of deliverables when preparing the estimate.

Facing a similar challenge? Tell us where things stand.

No specification document needed. Start with what you know.

Pricing and process

You do not need every detail decided to get started.

Start with advice or a design review

We can review your proposed approach before you commission implementation. The first step is to clarify the decision you need to make.

Pricing guide

Quoted for the consultation or review scope

For a standalone engagement, we agree on the material to review, the questions to address and the documentation required.

Initial feasibility checks and paid engagements

Initial checks needed to assess feasibility and prepare an estimate are generally free, on the understanding that you will commission the full development if it is found feasible. Extended validation, dedicated environments, prototypes, proofs of concept and detailed investigation reports may require a paid engagement.

An investigation or review commissioned in its own right is quoted as a separate paid service. We explain the scope and cost before any paid work begins.

  1. Tell us about the situation

    Share your goal, the problem and the environment, as far as you know them.

  2. Review the scope and cost

    We outline the investigation needed, scope, deliverables, cost and proposed process.

  3. Agree before work begins

    During the work, we share progress, confirmed findings and remaining constraints.

  4. Review the results and handover

    We validate the results under agreed conditions and prepare for deployment or the next step.

Need more technical detail?

Explore technologies and the detailed approach

Clarify the reasoning before you build or change software.

You are unsure which technology to choose, whether to retain existing components, or whether recurring faults warrant an architectural review. KomuraSoft helps plan Windows development and modifications around both platform constraints and current business needs.

Topics we can discuss

  • Compare technologies and architectures for a new application.
  • Define the responsibilities of UI, communications, background work and logging.
  • Review integration involving COM, ActiveX, C++/CLI and .NET.
  • Decide where to address mixed 32-bit and 64-bit requirements.
  • Compare modifying the current software with replacing it.
  • Plan the logs and tests needed before starting a fault investigation.

What a review considers

Does the design fit the goals and constraints?

We look beyond the age of a technology to its fit with existing assets, equipment, deployment environments, permissions and expected operating life. We distinguish feasible approaches from those needing prior validation.

Does it account for operation and maintenance?

We review responsibility boundaries, threading and resource management, exceptions, shutdown, logs and failure-path tests. The review identifies areas likely to become problems when software changes or faults occur.

What needs to be decided next?

We explain trade-offs, impact and remaining uncertainties, then prioritize investigation or changes. A recommendation should include its reasoning and the information still needed to make the decision, not simply name a preferred technology.

How a consultation proceeds

  1. Clarify the questions. Review the current architecture, difficulties, proposed options and conditions that cannot change.
  2. Compare the options. Examine documents or code as needed from implementation, operation and maintenance perspectives.
  3. Set out the next steps. Document the approach, cautions and validation tasks within the agreed scope.

Before you commission implementation

Advice and design reviews can be standalone engagements, or their results can lead into development or modification work. Tell us what you need to decide and what is already known. We confirm the scope and process before preparing an estimate.

For the conditions covering initial feasibility checks when you intend to commission full development, see advanced Windows development.

Questions before commissioning work

Can we commission advice before implementation?

Yes. You can start with technology selection or a design review before writing code. We agree on the questions to address, required deliverables and review scope.

Can you review older architectures involving COM or ActiveX?

Yes. We consider current behavior and operational constraints when deciding what to retain, where to change interfaces and what to replace.

Can we contact you before we can fully explain the problem?

Yes. Share the architecture, difficulties and options you are considering as far as you can. We can begin by clarifying which decisions need to be made.

Get in touch

A few lines about your situation are enough.

You do not need a detailed specification or technical terminology. Share what you know about:

  • The problem or the outcome you need
  • The software, devices and operating environment
  • Your preferred timeframe, even if it is not decided

There is no need to send confidential documents or passwords with your initial inquiry.

Example inquiry

We would like an independent review before proceeding with development, including how our existing COM components and threading design fit into the architecture.

No specification document needed. Start with what you know.

The discussion button opens our English contact page with ways to get in touch. “Send an email” opens a draft with the service name and blank prompts for your inquiry.