Web Development

Start with who needs web pages and small web apps and why. Around small firms and public bodies drive demand in Dubai, Abu Dhabi and the other emirates.

• List 10 offers or suppliers in the UAE with price per feature in AED and who buys.
• Interview 5 people from small firms and public bodies: what do they buy now, how often, what do they pay, what annoys them?
• Learn three terms: Version control (saving every change so you can go back); Input validation (checking what users type before using it); Responsive design (pages that fit any screen).
• Write a one-page brief: user, need, hoped-for price, and the rule that matters most.

Activity. Complete the market table, five interview notes and the brief.

Standard to meet. Price ten offers, interview five users, and state one need in one sentence.

Know the rule before the work. Main hazards here: insecure code and lost data. Hazard thinking means list each step, ask what could go wrong, and decide the control.

• Ask your local authority or free zone which licence, permit or inspection applies. Write the answer and the date you asked.
• For each step (gather needs; plan; code; test and secure; release) write the hazard and the control.
• Use a hierarchy: remove the hazard, replace it, separate people from it, change the way of work, then protective equipment last.
• Keep a one-page incident rule: who you call, what you stop, what you record.

Activity. Draw the flow and mark hazard and control at each step.

Standard to meet. Name a hazard and a control for every step, and answer the licence question in writing.

The work is a short chain: gather needs, plan, code, test and secure, release. Learn each link, then link them with records.

• Write a checklist for each of the 5 steps: input, action, check, output.
• Time each step three times and note the slowest.
• Record a defect or delay each time it happens: what, where, cause, fix.
• Measure features released without a defect; this is your main number.

Activity. Run the chain three times (simulated or real) and fill the log.

Standard to meet. Complete three logs, and give the slowest step a cause and a fix.

What you do not measure you cannot improve. Your main measure is features released without a defect.

• Define features released without a defect: what counts, what does not, and over what period.
• Draw a simple chart of the last 10 results and mark the average.
• Find the top two causes of loss with a tally sheet, then fix the biggest one first.
• Check measuring tools: are they accurate, clean and in date?

Activity. Collect a tally for one week and make a Pareto chart.

Standard to meet. Complete the tally, name the biggest cause, and plan one fix with a date.

Know the cost of one feature before you set the price. Include materials, labour, energy, transport, licence share, waste and a safety margin.

• Cost per feature = total cost divided by features sold (not made).
• Margin = (price minus cost) divided by price.
• Break-even units = fixed costs divided by gain per unit.
• Test the price with two users and write down the answer.

Activity. Build the cost sheet with AED on every line and have your mentor check it.

Standard to meet. Check that no cost is missing, and calculate the margin twice by different routes.

Customers return when you keep promises. Promise only what your workflow can deliver.

• Write a one-page offer: what is included, what is not, price, time, how you fix mistakes.
• Write a short script for the first call or visit.
• Agree dates in writing; confirm each change.
• Handle a complaint in four steps: listen, apologise for the impact, fix, record what changed.

Activity. Present the offer to two users and note changes.

Standard to meet. Write an offer with scope, price, time and a fix rule, and collect comments from two users.

Small, real and recorded. Change one thing at a time and learn quickly.

• Keep a daily log: date, units, cost, delays, defects, safety notes.
• Hold a 15-minute review each week with your mentor.
• Write down every complaint and what you changed.
• Take photos only where allowed and never of people without consent.

Activity. Complete 30 days of the log and four weekly reviews.

Standard to meet. Log 30 days, give each defect a cause, and keep weekly notes.

A decision beats a feeling. Compare plan with result and choose to scale, change or stop.

• Make a before and after table: cost per unit, defects, delays, repeat users.
• Write three lessons.
• Decide scale, change or stop, with the numbers behind it.
• Give two peers one strength and one fix each.

Activity. Present to a review room and collect one written comment from a user.

Standard to meet. Justify the decision with numbers, and give two peer reviews.

Small, tested steps beat big rushes.

• Break work into small tasks.
• Commit often with clear notes.
• Write tests for key paths.
• Review code before release.

Activity. Build and test a small form.

Standard to meet. Run the tests and show that they pass.

Most attacks use simple holes.

• Validate every input.
• Hash passwords; never store them plain.
• Use HTTPS.
• Keep libraries updated.

Activity. Review a sample form for five risks.

Standard to meet. List risks with fixes.

When a site breaks, a method beats panic. Reproduce, isolate, fix, test and write down what happened.

• Reproduce the fault and note the exact steps and browser.
• Check the latest change first and use version history to compare.
• Read error messages and logs; change one thing at a time.
• After the fix, add a test and write a short incident note.

Activity. Debug a given broken page with a deliberate bug and write the incident note.

Standard to meet. State cause, fix, time in minutes and one change to prevent repeats in the note.

On the slide: L1 Basic · Name version control and validation

Notes: Name version control, input validation and responsive design. Notes: show a form and ask learners what could be typed into it.

On the slide: L2 Awareness · Insecure code and lost data

Notes: Describe why insecure code and lost data are the main risks, with one control each. Notes: treat every form as a risk, validate input, hash passwords and store little data.

On the slide: L3 Foundation · Build and test a small form

Notes: Build a small form that validates input and passes a test. Notes: check that bad input is refused, that a change is saved with a clear note, and that the page fits a phone.

On the slide: L4 Practitioner · Run a feature release

Notes: Run gather needs, plan, code, test, secure and release for one feature with version history. Notes: the standard is tests passing and a code review before release; the target is features released without a defect.

On the slide: L5 Specialist · Analyse defects and decide

Notes: Analyse a month of defects and decide what to fix first. Notes: at AED 600 per feature and AED 300 cost the gain is AED 300, 50 per cent; break-even on AED 2,400 fixed costs is 8 features.

On the slide: L6 Advanced · Coach on review and incidents

Notes: Coach junior developers to review code and write an incident note after a fault. Notes: sample five changes a week for a test and a clear commit note; the method is reproduce, isolate, fix, test and write down.

On the slide: L7 Super expert · Design the development system

Notes: Design a development system with security checks, data limits, testing, release rules and a 12-month plan. Notes: at 40 features a month the gross gain is AED 12,000; present one security risk, one saving and a defect-free release target.