software development

Custom software can remove repetitive work, connect systems, support a specialized service, or give an organization more control over an important workflow. It can also become expensive and difficult to support when the problem, users, data, and operating responsibilities are not clear.

This checklist is designed for business owners, managers, and project leads preparing for a first conversation with a software team. You do not need to arrive with a technical specification. You do need a shared understanding of the work the software should improve.

1. Start with the business problem

Describe what happens today, where the process breaks down, and why the problem matters. Avoid starting with a feature list. A feature has value only when it helps a person complete a task, make a decision, or reduce a known risk.

Useful discovery notes include:

• The event that starts the workflow.
• The people, departments, customers, or partners involved.
• The information each person needs at each step.
• Delays, duplicate entry, manual handoffs, and common errors.
• The measurable outcome the new system should improve.

A good problem statement is specific enough to test. For example: “Dispatchers re-enter emailed orders into two systems, and drivers cannot see a verified change after leaving the terminal.” That is more actionable than “We need a dispatch app.”

2. Identify users, roles, and authority

List the user groups that will interact with the system. For each group, record what they can view, create, approve, correct, export, or administer. Treat menu visibility and actual permission as separate decisions.

Also identify actions that need a durable audit trail. A useful audit record explains who did what, when it happened, what record was affected, and—when appropriate—what changed.

3. Map the data and its source of truth

Every important field should have an owner and an authoritative source. Note whether the value is entered by a user, imported from another system, calculated, received from a device, or copied from a historical record.

Ask these questions early:

• Which existing records must be migrated?
• Which identifiers must remain stable?
• What validation rules prevent incomplete or conflicting data?
• How long must records and attachments be retained?
• Who can correct historical information, and how is that correction logged?

Data migration is usually its own workstream. A sample export is more useful than a screenshot because it reveals actual formats, gaps, duplicates, and relationships.

4. List integrations and notification paths

Document systems that the application must call or receive information from: accounting platforms, payment providers, maps, email or SMS services, identity providers, hardware, customer portals, and reporting tools.

For each integration, define the trigger, information exchanged, failure behaviour, retry rules, and support owner. Notifications need the same care. Specify the exact recipient rule, the event that creates the message, and what happens if delivery fails. Do not use a broad “send to everyone” fallback when recipient scope matters.

5. Define security and operational requirements

Security is not a feature added at the end. Discuss authentication, permissions, sensitive data, encryption, logging, backups, recovery, dependencies, and software updates during planning. The OWASP Application Security Verification Standard is a useful reference for turning general security concerns into testable requirements.

Operational requirements should also cover expected availability, performance, peak usage, supported devices and browsers, monitoring, error handling, and the process for urgent fixes.

6. Choose a focused first release

The first release should support a complete, valuable workflow for a defined group of users. It does not need to reproduce every exception and report in the current process.

Separate requirements into:

• Required for launch: the workflow cannot operate safely without it.
• Important next: useful after the core workflow is stable.
• Explore later: needs more evidence, data, or user feedback.

This makes estimates clearer and creates room to learn from real use before committing to lower-value complexity.

7. Define acceptance before development is complete

Agree on how each important workflow will be reviewed. Acceptance criteria should describe observable behaviour, including permission boundaries and failure cases—not only the successful path.

Plan for representative test data, user review, device and browser coverage, integration testing, and a controlled way to record decisions. If a project replaces an existing system, define how the two will run during transition and what evidence is required before the old process is retired.

8. Plan launch, support, and ownership

Before launch, identify the production environment, domain and certificate ownership, backups, monitoring, deployment method, administrator access, documentation, and the people responsible for support. Decide who can approve a release and how a rollback will work.

After launch, track support requests, errors, usage, and business outcomes. A maintenance plan should include security updates, dependency review, backups, recovery tests, and a process for prioritizing changes.

What to bring to a discovery meeting

• A one-page description of the current workflow and its main problems.
• A list of user groups and decision-makers.
• Sample forms, reports, exports, or screenshots with sensitive information removed.
• A list of systems, devices, and vendors that must integrate.
• Known deadlines and the reason behind each deadline.
• Questions about scope, delivery, security, support, and ownership.

NAM Software Solutions provides custom software development in Winnipeg, including connected cloud and mobile systems. If you are preparing a project, share the workflow and goals to begin a focused consultation.

A website redesign is not only a visual project. It changes how visitors find information, how search engines understand the site, and how the business receives calls, quote requests, applications, or orders. A new design can look better while performing worse if useful content, URLs, local details, or tracking are lost during the move.

This checklist helps Winnipeg businesses prepare a redesign that protects what already works and improves the experience for real visitors.

1. Define the business outcome

Choose the primary actions the website should support. Examples include requesting a quote, calling, booking, applying, purchasing, downloading a document, or signing in to a customer portal.

Record a baseline before changing the site: current search queries, important landing pages, conversions, call or form volume, page speed, accessibility issues, and common support questions. The baseline makes the redesign measurable.

2. Inventory every current URL

Create a list of pages, posts, files, forms, campaign URLs, and subdomains. For each URL, decide whether to keep it, improve it, merge it, redirect it, or retire it.

Use a permanent redirect when an old page has a clear replacement. Do not redirect every removed page to the homepage; that creates a confusing experience and can hide broken content decisions. Pages that were accidental demos, spam, or completely unrelated may be better removed with a clear not-found or gone response.

3. Organize content around visitor questions

Navigation should reflect how customers think about the service, not the company’s internal structure. Each core service page should explain:

• Who the service is for.
• The problem or task it addresses.
• What is included and what information is needed to begin.
• The process, constraints, and next step.
• Related services or resources that help the visitor continue.

Replace theme-demo text, placeholder paragraphs, unsupported awards, and generic superlatives with specific information a customer can use. A shorter accurate page is more trustworthy than a long page filled with claims that cannot be verified.

4. Make local information consistent

For a Winnipeg business, use one consistent public business name, phone number, email address, street spelling, city, province, and postal code across the website and business profiles. Fix differences in the footer, contact page, map, structured data, and external listings.

If customers do not visit the address, configure the Google Business Profile as a service-area business and follow Google’s address-visibility rules. The public website and profile should accurately reflect how the business serves customers.

5. Separate design from development decisions

Design covers content hierarchy, navigation, layouts, components, interaction states, and responsive behaviour. Development turns those decisions into a working, maintainable system.

Before approving layouts, test them with real page titles, long and short content, error messages, forms, tables, and mobile screens. Placeholder content hides problems that appear when the site contains actual information.

6. Include accessibility from the start

Use semantic headings, keyboard-accessible navigation, visible focus states, labelled form fields, useful alternative text, sufficient colour contrast, and error messages that explain how to recover. The current Web Content Accessibility Guidelines (WCAG) 2.2 provide testable success criteria.

Accessibility checks belong in design review, component development, content entry, and final testing—not only in a scanner at the end.

7. Protect technical search foundations

Every indexable page should have a descriptive title, a useful main heading, a concise meta description, a self-referencing canonical URL, and crawlable internal links. The site should also provide a focused XML sitemap and a robots.txt file that does not block required public assets or admin AJAX.

Review structured data for the organization and local business, but do not add properties that are not visible, accurate, or supported. Follow the Google Search Essentials and avoid paid or automated link schemes.

8. Verify forms, analytics, and privacy

Test each public form with synthetic information and an approved test destination. Confirm validation, spam protection, consent language, success and error messages, recipient ownership, and how submissions are retained. Never use a real customer or project participant as a test recipient.

Check analytics events for the actions that matter: submitted forms, calls, downloads, purchases, or portal sign-ins. Update the privacy policy when tracking, cookies, or data collection changes.

9. Run a controlled launch checklist

• Back up the database, uploads, source, web-server configuration, and certificates.
• Verify redirects with both old and new URLs.
• Crawl the site for broken internal links, accidental noindex tags, duplicate titles, and missing canonicals.
• Test representative pages on desktop and mobile viewports.
• Check forms, login, search, maps, downloads, and integrations.
• Validate the XML sitemap, robots.txt, and structured-data JSON.
• Monitor server errors, application logs, indexing, and conversions after launch.

10. Improve the site after launch

A redesign is the beginning of a measurement cycle. Review search queries, local-profile activity, form quality, support questions, page engagement, and conversion paths. Update service pages and publish useful articles when customer questions reveal missing information.

NAM Software Solutions provides website design and website development in Winnipeg. To discuss a redesign, share the current site, goals, and important workflows.