Requirements
Templates fail when they are long enough to feel thorough and generic enough to be filled in without thinking. This one is deliberately short: every section exists because a supplier cannot price the work without it.
Problem, users, environment, constraints, what you want back, how you decide. A paragraph each is enough to start.
Requirements nobody intends to check teach suppliers to treat the whole document as decorative.
If a colleague who does not know the work cannot say what you want after one read, no supplier will either.
What happens today, what it costs in time or money or lost customers, and what should be true when the work is finished. No technology in this section.
Suppliers use this to decide whether to bid at all, and to judge whether the approach they have in mind actually solves your problem or just the part of it you described most vividly.
Each kind of user, roughly how many there are, and what each needs to do. Distinguish people inside your organisation from customers, and note anyone with different permissions.
This drives more of the price than anything except payments. Two user types with different views is a different piece of software from one type with a single view.
What already exists, what must keep working, and what data has to move between systems. Name the products by name, and say whether each has an API and whether anyone has used it.
Integrations with undocumented or legacy systems are where estimates go wrong most often. Saying so up front gets you an honest price instead of a cheerful one.
Budget range, the deadline and the real reason behind it, regulatory obligations, and who has to maintain the result afterwards.
The maintenance question is quietly important. A solution built in a stack nobody in your organisation can touch is a different proposition from one your existing team can extend, even if both work equally well on day one.
State the format: an itemised breakdown, days per item, a range rather than a single figure, the assumptions the price depends on, and the name of the person who would do the work.
Ask explicitly what you own at the end. Code, accounts, design files, and when ownership transfers. Leaving this to the contract stage is how it ends up conditional on final payment.
Criteria with weightings, the questions deadline, and the date you will choose. If price is not the main factor, say what is.
Publishing this changes the proposals you get. Suppliers write to the criteria they can see, and you get answers that are comparable rather than a pile of documents in six different shapes.
Yes, but ask for the assumption list alongside the fixed price. A fixed price without stated assumptions is a fixed price until the first surprise.
That is the good outcome. A supplier who asks nothing before quoting has either done this exact project before or is not thinking about yours.
Khmelnytskyi, Ukraine
Full-Stack Developer — Websites, Apps, Servers, Databases, AI, SEO & QA
Full-stack developer working across the entire stack — websites, apps, servers, databases, AI integrations, SEO, and QA. Languages & Core: writes code in JavaScript, TypeScript, Python, PHP, Go, and Rust. Architects scalable systems for large-scale projects. Frontend & Interfaces: builds websites and web applications with React and Next.js. Crafts responsive interfaces with Tailwind CSS, Radix UI and Shadcn, adds smooth animations with Framer Motion, and interactive charts with Recharts. SEO Audit & On-Page Optimization: semantic keyword research, resolving technical indexing issues, and optimizing page load speeds. Structures page architecture, meta tags, and multi-language support (i18n). Copywriting & Content Strategy: writes technical articles, drafts precise content briefs for writers, and develops content plans. QA & Testing: full-cycle testing for websites, web services, and Android apps — manual QA for UI/UX and business logic, plus automated testing with Jest, Vitest, Playwright and E2E. Backend, Cloud & Databases: complex API integrations of any scale. Builds servers with Node.js (Express, Fastify). Works with PostgreSQL, MySQL and MongoDB, ORMs (Prisma, Drizzle), and cloud infrastructure (Supabase, Firebase, Cloudflare). Browser Extensions & Automation: develops Manifest V3 browser extensions for Chrome, Edge, Firefox and other browsers. Builds web scrapers for complex data extraction using Puppeteer and Playwright. AI & Intelligent Agents: builds custom AI agents and integrates LLMs from OpenAI, Google Gemini, and Anthropic Claude via API, including Claude Code setups. Servers & DevOps: Linux (Ubuntu) and VPS administration — setup, updates, real-time monitoring, secure process isolation, Nginx, PM2, and CI/CD deployment via GitHub Actions. Telegram Bots: develops advanced Telegram bots (Telegraf, Grammy) integrated with AI, payment gateways, Google Sheets, and crypto exchanges. Desktop Applications: builds cross-platform software for Windows and macOS using Electron and Rust. Additional expertise: site development and customization with WordPress and Astro.
AI & Distributed Systems Architect | Enterprise AI, RAG, Cloud, Blockchain | Advisory & Fractional Leadership
AI and distributed systems architect providing advisory and fractional leadership on enterprise AI, RAG pipelines, cloud architecture and blockchain-backed data systems.
