How to use a project brief with BarmajTek
This project brief guide explains what we need before estimating custom development, integrations, or architecture consulting. Clearer briefs produce faster, more accurate proposals. Send your brief via Start a project or email.
A project brief is not a contract. It is a preparation document that helps the team understand the problem, users, and constraints before proposing a ready product or a custom build.
Core information
Describe your organization, sector, and expected users (staff/customers). List current systems (Excel, WhatsApp, foreign software, paper) and what breaks daily: bookings, invoices, attendance, dispatch, inventory, or other.
Define the outcome you want to measure in 30–90 days (for example fewer no-shows, faster invoicing, fewer manual calls). Note launch deadlines or peak seasons if any.
Technical and compliance needs
Say whether you need a mobile app, web console, JoFotara or payment gateway integration, or sync with accounting systems. Note if data is sensitive or sector-restricted.
If you have an internal engineering team, describe their role: full delivery from BarmajTek or architecture consulting only? That changes the proposal shape entirely.
Budget and ownership
A rough annual or project budget range helps us recommend a ready Tek product versus custom build. We do not need precise finances in the first brief, but honesty shortens unhelpful rounds.
SaaS products stay licensed under subscription plans, while custom development discusses code and data ownership in the written proposal. The project brief prepares that conversation without replacing it.
Next steps
After we receive your project brief we review fit within business days, then propose a short call or written path: ready product, custom build, integration, or a mix. If we are not the right fit, we say so clearly.
To start a project brief now, use Start a project on barmajtek.com and attach non-confidential supporting files. Avoid sending passwords or real customer data in the first brief.
Quick checklist before sending
Before sending a project brief, confirm you answered: who is the user? what is the daily bottleneck? what measured outcome? which current systems? what time constraints? rough budget level? and whether you prefer a ready product or custom build when both could fit?
Attach non-confidential screenshots or public links if available, and avoid real customer data. If you already have an NDA, tell us before sharing sensitive details.
What happens after review
We may ask a short clarification by call or message. Then you receive a proposed path: product demo, project estimate, or a clear decline if we are not the right fit. A strong project brief saves weeks of vague discussion.
Retention of project briefs follows the Privacy Policy. If you request deletion after the conversation ends, we can do so within reasonable operational and legal limits.
Suggested project brief format
You can write the project brief as bullets: 1) organization and sector, 2) users, 3) daily problem, 4) current systems, 5) measured 90-day outcome, 6) technical constraints, 7) rough budget, 8) needed date.
If the brief is incomplete we will ask again instead of guessing the wrong scope. A strong project brief respects both sides’ time and speeds a clear proposal on barmajtek.com.
Remember: a project brief is a preparation document in the Start a project journey — not a substitute for the contract, Privacy Policy, or Terms of Use when a formal agreement is signed later.