New system development
Building an application or platform that does not exist yet, usually replacing a manual or spreadsheet-based process.
Contacts
All enquiries are handled by email. A message that describes the system, the problem and the constraints receives a technical answer; a message without that context can only receive a request for more information. Everything below explains what is useful to include and what happens after a message arrives.
Which process or product the system supports, who uses it, and what currently happens when it fails or is unavailable.
Existing applications, languages, databases and hosting arrangements, including anything that must remain unchanged.
The state you want to reach, described in operational terms rather than as a list of features.
Other systems that hold related data, and whether they can be modified or must be treated as fixed.
Compliance requirements, data residency rules, budget boundaries, fixed deadlines or internal policies affecting the work.
Who will be involved in technical decisions and approvals on your side, so the right people are included from the start.
Building an application or platform that does not exist yet, usually replacing a manual or spreadsheet-based process.
Extending, restructuring or taking over software that is already running in production.
An independent assessment of a system, a proposed rewrite, or a technical due diligence exercise.
Connecting two or more systems, defining contracts and handling reconciliation between them.
Moving hosting, making environments reproducible, or building deployment pipelines.
Ongoing monitoring, patching, incident handling and planned improvement for a live system.
Your message is read by an engineer, not a sales desk. If the request falls outside what we can competently deliver, we say so.
A short written exchange fills the gaps: constraints, existing systems, data volumes, and who needs to be involved.
A call or written discussion with the people who would perform the work, focused on architecture options and risks.
Scope, delivery sequence, assumptions and deliverables are set out in writing before any commitment is made.
We do not state a fixed response time. Messages are answered in the order received, and enquiries requiring input from more than one engineer take longer than those that do not. If a message needs information we do not yet have, the reply will say precisely what is missing rather than restate the question.
The structure below shows the fields we ask for in an email enquiry. It is a reference outline, not a submission form: please send the same details by email to meijerkevin06@gmail.com.