Start a web design, development or AI project with a useful brief.
The structured brief asks for the business goal, current site or product, project type, approximate budget, timing, features and integrations. It does not upload anything to Wemaxa: submitting opens a prefilled email to sales@wemaxa.com in your email client.
Project brief assembly
Form inputs become structured scope tokens before the email handoff is created.
A good brief can be short and specific
You do not need a finished technical specification. Describe what the business or product needs to achieve, who uses it, what already exists and what absolutely must be included. A clear problem statement is more useful than a list of technologies chosen before the workflow is understood. If there is an existing site or application, include the URL and explain what is not working about it.
Reference sites are useful when you say what you like about them. A reference can communicate density, typography, navigation, restraint, motion, editorial style or the general level of polish you expect. It should not be treated as a request to copy another company's design.
Tell us what already exists
Existing assets can materially change scope. A usable logo, a finished brand guide, final copy, product photography and clean product data reduce different kinds of work. An existing CMS may already contain hundreds of URLs that need to be migrated. An internal API may expose the data the new application needs. The first brief should mention these assets even if Wemaxa has not yet reviewed them.
Also mention ownership of the domain, hosting and important third-party accounts. A project can be delayed late in the process if no one knows who controls DNS or the old analytics property. Access credentials should not be emailed at this stage, but account ownership should be clear.
Tell us what you are building.
What the work actually involves.
Include hard constraints early
If the project has a required CMS, hosting environment, identity provider, payment gateway, launch date, procurement rule, regulatory constraint or internal API, include it. These facts can change architecture and schedule. They should not appear after the visual design is approved.
For enterprise systems, include current applications, user roles, migration needs and internal stakeholders. If a requirement is uncertain, say that too. Unknowns are normal. The point of discovery is to resolve the ones that matter before implementation commits to an expensive direction.
Budget and timing
A budget range helps Wemaxa recommend a realistic shape. It can distinguish a focused launch from a larger custom design, or reveal that an enterprise roadmap should be split into discovery and implementation. The range does not need to be exact. It is commercial context for the first conversation.
Timing should distinguish a genuine deadline from a preference. A legal launch, event or migration deadline is different from wanting the site soon. Content approval, client review and third-party account verification can all affect the schedule, so a proposal needs enough time for those external steps.
Do not send secrets in the first brief
Do not put passwords, API keys, payment credentials, private customer records, production database exports or other secrets in the initial email. If Wemaxa needs access after scope is agreed, credentials can be exchanged through an appropriate secure channel. The first message should describe the system without exposing it.
If the project involves sensitive information, explain the category and the operating requirement. For example, say that the application stores confidential customer records or requires restricted internal access. Do not attach the actual records simply to demonstrate the problem.
What happens after the brief
Wemaxa can review the request and reply with clarifying questions, a recommended service path or a proposal/discovery conversation. A small project may be clear enough to quote after a short exchange. A larger application may need a structured discovery step before a responsible estimate is possible.
The purpose of this order page is not to turn a custom project into a checkout item. It is to collect enough context that the first reply can discuss the project rather than asking for the basic information the site could have requested up front.
The project brief is a routing document
The purpose of the order page is to provide enough context for a useful first response, not to force the client to write a complete technical specification. The business goal, current site or system, audience, must-have features, integrations, timeline and budget range are usually enough to decide what questions should come next.
If the project is a redesign, the existing URL is especially useful because it exposes current content volume, platform assumptions and migration risk. If the project is new, reference sites can communicate a level of density, interaction or visual ambition when the reasons for liking them are explained.
Describe AI requirements as tasks
For AI integration, describe what should happen rather than only naming a model. Examples include searching an internal knowledge base, extracting fields from documents, summarizing long records, triaging support, analyzing images, generating structured drafts for review or allowing an authenticated assistant to call specific application tools.
Also describe what data the feature may access and whether any information must remain local. Those boundaries can influence provider choice, retrieval architecture and authentication before the interface is designed.
Do not send credentials in the first message
The first project brief should not include passwords, API keys, payment credentials, private customer records or production database exports. The team can establish an appropriate secure method for access after the project relationship and technical requirements are understood.
For sensitive projects, describe the category of data and the handling constraint without attaching the data itself. That is enough to begin discussing architecture and compliance requirements.
What happens after the brief
Wemaxa can respond with clarification questions, a recommended scope, a request for a discovery step or a proposal path. Projects with clear page types and content may be quoted directly, while integration-heavy applications may need a technical discussion first.
The goal is to reduce ambiguity before design starts. That protects both sides from treating an unspoken assumption as included work after the project is already underway.
What we clarify before committing to the build.
Questions that usually affect scope.
Does submitting this form store my data?
No. The form in this static build prepares a mailto message in your email client. It does not post the entered project information to a Wemaxa database.
Do I need a complete specification?
No. A clear description of the goal, users, current state and must-have features is enough for an initial conversation.
Should I include my budget?
A range is useful because it helps Wemaxa recommend a realistic scope or phased approach.
Can I attach credentials?
Do not send passwords or API keys in the first project brief. Access can be arranged later through a secure channel.
What if the project is enterprise-scale?
Use the same brief or email enterprise@wemaxa.com with the current systems, integrations, user roles, migration needs and known constraints.
Brief completeness check
The secondary scene visualizes required context becoming ready for a useful first reply.
Discuss start a project with Wemaxa.
Send the project brief or open a direct sales conversation.