A barbershop owner wants customers to see his services and request a time to visit. During a consultation, the conversation might settle on a small website with a service list, photographs and an appointment request form. That is a project someone can describe, build and review.
MCBMichigan's development grants cover agreed project work. The useful question is what the approved project includes and what you will need to keep it running afterward.
The scope gives the grant a practical meaning
An approved scope sets out the work covered by your development credit. Depending on the need, that could be a website, a business app or an automation. The consultation helps establish which approach fits the work you want to improve.
For the hypothetical barbershop, the first version could include the pages and request form described above. A system for staff scheduling and payroll would be a different undertaking, even if both ideas came up in the same conversation.
Before work begins, read the scope against the problem you brought to the consultation. Check what a customer will be able to do and how your business will receive the information. Ask about anything you expect that is missing from the description.
Development credit is applied to the project we agree to build. It does not mean that every idea discussed has been approved, or that an unlimited amount of future work is included.
Building the tool and operating it are separate costs
A finished website needs somewhere to run. A custom domain has its own registration and renewal. An app may depend on services that charge for messages, storage or AI use.
The mix depends on the project. A website that displays services and receives an occasional inquiry has different requirements from an app that sends reminders throughout the day. We should identify the services the proposed work relies on while deciding its scope.
Ask who will hold each account, who pays its charges and how you can check usage. Find out which costs recur and which may change as more people use the tool. Have those responsibilities confirmed before agreeing to the plan.
There is no need to arrive with a hosting provider or a list of technical services already chosen. Bring your budget and explain how the business expects to use the result. Those details help us work out a practical setup.
Your business supplies the context
Even a small project needs decisions from the person who knows the business. For a website, that may mean confirming opening hours and choosing photographs. For an internal app, it may mean showing how staff record a job and deciding who can see its details.
Collect material you already have before spending time creating something new. A service list, a blank form or a few examples of work can help establish what belongs in the first version. Tell us if you need help deciding what to prepare.
Plan time to review the work. Check the wording and try the main tasks yourself. Your feedback helps catch a service description that is inaccurate or a step that does not fit how people actually work.
Changes can be discussed without losing track of the first project
Sometimes testing reveals a correction needed to make the agreed task work. Sometimes it suggests a new feature. Raise both, and ask how each affects the scope and delivery plan.
Additional work can be considered as another project. If development credit is unavailable, the work can be quoted as a paid project. A price and funding decision should be settled before that work begins.
Ongoing support is a choice to discuss based on what you need after launch. You may want help with updates, or you may prefer to arrange maintenance yourself. Ask what the handover includes and what support would cover before choosing an arrangement.
Start with the business need. You can request a consultation without a finished specification. We can use that conversation to work toward a scope you understand and a clear account of the responsibilities that come with it.
