Software Development and Full-Stack Engineering

01Purpose and scope

• This manual supports the course Software Development and Full-Stack Engineering. It describes how working teams take a software product from a stated need to a running system that users can reach through a browser or app, and how they keep that system healthy after release. It is written as a reference for engineers, technical leads, product partners and learners who want to see what the daily work looks like, not only the concepts.
• The scope covers the front end (the code that runs in the user's browser or client), the back end (services, business logic and application programming interfaces), and the data layer (databases, caches and file storage). It also covers the delivery path that connects them, including source control, automated builds, environments, and release practices. It does not cover embedded systems, game engines or machine learning model training, where the constraints and tools differ enough to need their own guidance.
• Full-stack work is a matter of degree. Some engineers own features from a form field to a database table, while many teams split those responsibilities. This manual treats full-stack engineering as the ability to reason across the layers, make sound trade-offs between them, and communicate clearly with the people who depend on each one.

02Core principles

• Start from the user's task and work inward. A slow report page is usually a question about what data is needed and when, not only about how the query is written. Engineers who begin with the user's path tend to avoid building endpoints that nobody calls and screens that display data in the wrong order.
• Keep contracts explicit. The boundary between the front end and the back end is an interface agreement. Define request and response shapes, error formats, pagination rules and authentication expectations in a written form, such as an OpenAPI description or a shared schema file, so both sides can change without guessing.
• Prefer simple, reversible decisions. Choosing a framework, a database engine or a hosting model commits the team for years. Where a choice is cheap to reverse, decide quickly. Where it is expensive, gather evidence, write down the reasoning, and name the conditions that would trigger a review.
• Treat data as the long-lived asset. Code is replaced often. Schemas, stored records and audit trails outlive several rewrites. Changes to tables and records need migration scripts, backfill plans and a way to roll back.
• Make failure visible. Logs, metrics and error reports should show what broke, for whom, and how often. A system that fails quietly is harder to fix than one that fails loudly with clear messages.

03Planning and preparation

• Begin by writing a short problem statement that names the user group, the task they need to finish, and the measure that will show whether the change worked. Ask the product owner or requester to confirm the scope in writing. Scope that is only agreed in a meeting tends to grow silently during development.
• Inventory the existing system before proposing changes. Identify the services, tables, background jobs, third-party integrations and scheduled tasks the feature touches. Check which parts have tests, which have documentation, and which are owned by another team. This inventory often reveals that a small feature depends on a fragile import job or an undocumented field.
• Estimate in ranges and mark the unknowns. Engineers can usually size the front end and the API work with reasonable confidence. Data migrations, third-party approvals and performance under real load are harder to estimate and should be flagged as risks rather than hidden inside a single number.
• Set up the environment early. Confirm that every engineer can run the application locally with seeded test data, that the staging environment matches production closely enough to catch configuration problems, and that secrets are stored in a managed secrets service rather than in source files. Tooling choices such as the language version, package manager, container setup and linting rules should be recorded in the repository so a new contributor can reproduce the setup without asking a colleague.
• Decide who owns which decisions. A typical split assigns product decisions to the product owner, interface contracts to a shared agreement between the front end and back end leads, and data model changes to the team that owns the database. Write these down in the team's working agreement.

04Recommended workflow

1. 1
   : Write the user story and acceptance criteria in plain language. Each criterion should be something a tester can check, such as a form rejecting an empty postal code or a list loading within two seconds for a dataset of ten thousand records on the staging hardware.
2. 2
   : Sketch the data model and the API contract before writing feature code. Show which entities change, which new fields are required, and what each endpoint accepts and returns. Review the sketch with the other side of the boundary. Most integration bugs are found at this step at low cost.
3. 3
   : Create a branch from the main line and keep it short-lived. Commit in small units that each leave the test suite passing. Use commit messages that explain the reason for the change, not only the action.
4. 4
   : Build the back end first when the feature depends on new data rules, and build the front end first when the main risk is usability. In either order, write automated tests for the business rules and the endpoints before or alongside the code. A unit test for a pricing rule and an integration test for the endpoint that calls it cover most of the risk in typical work.
5. 5
   : Write migrations as separate, reviewed scripts. Make them additive where possible: add a nullable column, deploy the code that writes to it, backfill existing rows in batches, then add the constraint. Test each migration against a copy of production-shaped data to measure run time and locking behavior.
6. 6
   : Implement the front end against the agreed contract, using mocked responses for parts that are not ready. Check loading states, empty states, error messages and keyboard navigation. Test on the browsers and devices the users actually use, which the product owner should be able to name from analytics or support records.
7. 7
   : Open a pull request with a description that states the purpose, the main design choices, the test evidence and any known gaps. Request review from one person who knows the area and one person who will be affected by the change. Respond to comments with code changes or a written reason for declining them.
8. 8
   : Merge into the main line only after the automated pipeline passes. Deploy to staging, run the acceptance criteria manually or with end-to-end tests, and record the results. Schedule production deployment for a window the on-call engineer can cover, and keep the release notes current.
9. 9
   : Release with a rollback plan. For a web service this often means deploying a new version alongside the old one and shifting traffic gradually, with a tested path to revert. For schema changes, confirm that the previous application version can still run against the new schema during the transition.

05Quality checks, risk controls and compliance

• Automated tests form the first layer of quality control. A practical suite usually includes unit tests for business rules, integration tests that exercise endpoints against a real database engine, and a smaller set of end-to-end tests that drive the browser through critical paths such as sign-in, checkout or record submission. End-to-end tests are slower and more fragile, so keep them focused on flows where a failure would hurt users or revenue.
• Static analysis, linting and dependency scanning catch a different class of problems. Type checkers catch mismatched fields before runtime. Dependency audits flag libraries with known vulnerabilities, although the findings need human triage because many alerts do not apply to the way the software is used.
• Security needs deliberate attention at every layer. The OWASP Top 10 is a widely used list of common web application risks, including injection, broken access control and security misconfiguration, and it is a sound checklist for reviews. Input validation belongs on the server even when the front end validates too. Authorization should be checked on each request that reads or changes data, not only when a page loads.
• Accessibility is part of quality for user-facing work. The Web Content Accessibility Guidelines (WCAG) published by the W3C give testable success criteria for color contrast, keyboard operation, form labels and focus order. Automated checkers find only a portion of issues, so pair them with manual keyboard testing and, where possible, testing with assistive technology.
• Privacy and data protection rules vary by jurisdiction and by the type of data held. Regulations such as the EU General Data Protection Regulation and US state privacy laws set obligations around consent, retention, access requests and breach notification. This manual does not replace legal advice. Confirm current requirements with the organization's privacy or legal team and the authoritative text of the applicable law.
• For regulated or high-risk fields such as health records, financial transactions or safety-critical controls, this guidance does not replace qualified professional judgment, approved procedures or required authorization. Those domains usually require formal change control, validated tooling, and sign-off by people with the appropriate accountability. Treat the practices here as a baseline that the regulated process builds on, not as a substitute for it.
• Risk controls include feature flags for gradual exposure, rate limits on public endpoints, backups with tested restore procedures, and documented runbooks for common incidents. A restore that has never been tried is a hope, not a control. Schedule restore tests and record how long they took.

06Collaboration and documentation

• Good full-stack work depends on steady communication between designers, product owners, front end and back end engineers, data specialists, testers and operations staff. Short daily check-ins help, but the most useful habit is writing down decisions where people can find them later. A decision record that states the context, the options considered, the choice and the consequences saves hours of repeated debate.
• Documentation should be close to the code and kept current. A README should explain how to run the project, how to run tests, and where configuration lives. API documentation should be generated from the contract where possible, so it does not drift. Architecture notes should describe the major components, the data flow between them, and the places where failures are most likely.
• Code review is both a quality control and a teaching tool. Reviewers should look for correctness, clarity, test coverage and consistency with existing patterns. They should avoid rewriting the author's approach when the existing approach is acceptable. Reviews that arrive within a working day keep work moving; a pull request that waits three days tends to be rebased into conflicts.
• Working with non-engineers requires translation. A product owner may ask for a real-time view, but the cost of real-time updates depends on the infrastructure. A short written option set, with the trade-off in plain terms, lets the owner choose with accurate expectations.
• Handoffs to operations and support need specific material: how to recognize the feature's failure signs, which logs to read, who to page, and what customer-facing messages to use. These belong in the runbook and in the release notes.

07Measures and continuous improvement

• Measure what the team can influence and what users experience. Useful indicators include lead time from commit to production, deployment frequency, change failure rate, time to restore service after an incident, and the share of critical paths covered by automated tests. Page load time, error rate per endpoint and the number of support tickets tied to a release show whether users are better served. Targets should be set by the team against its own baseline, not copied from another organization.
• Be careful with indicators. A target for test coverage can encourage shallow tests that assert nothing useful. A target for story points can encourage inflated estimates. Pair each measure with a question about what behavior it might distort, and review the measures together every few months.
• Retrospectives work when they lead to specific changes. After each release or incident, list two or three improvements, assign an owner and a date for review, and check whether the change helped. A retrospective that produces a long list with no owners usually changes nothing.
• Practice changes across contexts. A startup building a prototype may accept a single database instance, manual deployments and limited monitoring, as long as it understands the risk of losing customer data. A team running a payment system needs stricter change control, separation of duties and audited access. A team maintaining a large legacy application may spend most of its effort on migration and dependency upgrades rather than new features. Each context involves trade-offs between speed, cost, reliability and the ability to change the system later.
• The limits of any single approach should be stated openly. Microservices, serverless functions, monolith designs and managed platforms each shift work between the team and the vendor, and each adds specific operational costs. Choose the design that the team can operate well, and revisit it when the load, the team size or the requirements change.

08Common mistakes and how to prevent them

• Building the interface before the data rules are settled. This produces screens that must be rewritten when the back end changes. Prevent it by agreeing the contract and the main validation rules before the screen work begins.
• Putting business logic only in the front end. Any rule enforced only in the browser can be bypassed. Keep authoritative rules on the server and use the front end for convenience and feedback.
• Shipping schema changes and code changes in the same step without a transition plan. A failed deployment can leave the application unable to read its own data. Use additive migrations and confirm that old and new versions can coexist for the release window.
• Relying on manual testing for critical flows. Manual checks miss regressions that appear after unrelated changes. Write end-to-end tests for the few flows that matter most and keep them stable.
• Hard-coding configuration and secrets. Values such as database addresses, API keys and feature settings should come from the environment or a managed configuration service. Keep a template file that lists the required settings without containing real values.
• Letting dependencies age without review. Old libraries accumulate security issues and make later upgrades harder. Schedule regular dependency updates in small batches and read the changelogs for breaking changes.
• Skipping the restore test. Backups that have never been restored often fail when needed. Run a restore into a separate environment on a regular schedule and record the result.

09Practical checklist

• Confirm the user problem, the acceptance criteria and the success measure in writing before starting.
• Inventory the existing components, data, jobs and integrations that the change touches.
• Agree the API contract and data model with the other side of each boundary.
• Keep branches short, commits small and each commit passing the test suite.
• Write migrations as reviewed, additive steps with a tested rollback or transition plan.
• Enforce authorization and validation on the server for every request that reads or writes data.
• Run automated tests, static checks and dependency scans before merging.
• Check accessibility with automated tools and manual keyboard testing for user-facing screens.
• Confirm privacy, security and regulatory requirements with the responsible owner for the data involved.
• Document setup, configuration, runbooks and decisions where the next engineer will look.
• Deploy with a rollback path, watch error rates and latency after release, and record the outcome.
• Hold a short retrospective and assign specific follow-up actions with owners.

★Learning sources

• Micro Degree: Software Development and Full-Stack Engineering
• Micro Degree: Data Analytics Applications
• Micro Degree: Azure Cloud Fundamentals
• Micro Degree: Google Cloud Platform Basics