Questions we hear before a project starts

No. The determining factor is the clarity of the problem, not the size of the organization. Small businesses with a well-defined operational bottleneck are often clearer projects than large organizations that have not agreed internally on what they need.

The products listed on this site are EH DESIGN initiatives at different development stages, and each product page states its stage openly. Some are ready for guided walkthroughs and pilot discussions; none are presented as mass-market packages with published customer results.

A description of the workflow that is causing difficulty, who is involved in it, what systems you use today and what you would like to be different. Exact requirements are not expected. Clarity about the problem matters far more than a technical specification.

Pricing follows scope and risk. Discovery and consulting are quoted as fixed-scope phases. Implementation is quoted after requirements are documented, because an estimate given before that is a guess presented as a number. Ongoing support is agreed separately.

For custom development the client owns the delivered source code and all business data, and ownership terms are stated in the agreement before work starts. Where an EH DESIGN product foundation is licensed rather than built from scratch, that distinction is made explicit up front.

Only with written permission. Where a client prefers confidentiality, the work is either not published or described in technical terms without identifying the organization. We do not publish client names, revenue figures or performance claims we cannot verify.

More than most clients expect. Discovery sessions, review of increments and acceptance testing require real availability from the people who know the process. A project where nobody internally has time is a project built on assumptions, and that is the most common cause of rework.

Change is expected, so it is managed rather than resisted. A change is assessed for its effect on scope, schedule and cost, then either accepted into the current release or added to the roadmap. What we avoid is absorbing changes silently until the delivery date quietly moves.

Yes. Handover includes role-based training for users and administrators, operations and setup documentation, and notes on known limitations. A system that only the developer understands is a liability, so independence from us is a delivery goal rather than a risk.

Every project includes a defined stabilization window after go-live for corrections found in real use. Beyond that, ongoing support and improvement can be agreed as a separate arrangement covering issue response, dependency and security updates and planned enhancements.

Yes. Offline-capable desktop systems with a local database are a normal delivery pattern for warehouse, trading and field operations. On-premise hosting is supported where regulation, confidentiality or connectivity makes it the right choice, with a documented backup procedure as part of handover.

Authorization is enforced server-side on every operation rather than by hiding interface elements. Inputs are validated on the server, credentials are hashed, secrets stay outside the codebase, write operations produce audit records and sensitive data is never written to logs. Security is part of the build, not a review at the end.

No. Most operational value comes from deterministic logic and clean integrations. AI is introduced only where the input, output and failure mode are understood, where the data boundary is acceptable and where a human checkpoint exists for decisions that carry consequences.

Often yes, and it is frequently the better decision. We assess the current system’s architecture, data model and maintainability, then recommend extending, integrating or replacing it. A recommendation not to rebuild is a legitimate outcome of the assessment.