Building digitalproducts frominterface toinfrastructure.
Altaf Shaik — Full-Stack Developer. Building digital products from interface to infrastructure.
I'm a full-stack developer based in Hyderabad. I design and build web applications end to end — the interface people use, the API behind it, and the data model underneath.
That means the interface people actually touch, the API that serves it, and the database schema holding it together — designed as one system rather than three handoffs between three people.
Angular and TypeScript are where I spend most of my working day. Alongside them I build with React, Next.js, Node and .NET, which means I can pick the stack that fits a job instead of pushing every project through the same one.
The work I enjoy most is the kind where the data is messy, the workflow is specific to one business, and nothing off the shelf quite fits.
Based in
Hyderabad, India
Day to day
Angular · TypeScript · REST APIs
Also build with
React · Next.js · Node · .NET
Open to
Freelance and contract work
03Services
What I can build or fix for you
Four kinds of work, from a one-afternoon repair to a system you'll run your business on.
bug fixes
site rescues
restaurant websites
admin panels
live dashboards
REST APIs
database design
performance work
maintenance
redesigns
bug fixes
site rescues
restaurant websites
admin panels
live dashboards
REST APIs
database design
performance work
maintenance
redesigns
I take on existing sites and applications: tracking down the bug that only happens on mobile, untangling a build that stopped deploying, replacing a plugin that broke after an update, or picking up a codebase the last developer walked away from. I start by reproducing the problem, then fix the cause rather than the symptom.
What you get
Bug diagnosis and repair
Performance and loading-speed work
Dependency and framework upgrades
Ongoing maintenance and small changes
Usually built with
JavaScript
TypeScript
Angular
React
Node.js
Not sure which of these you need? Describe the problem and I'll tell you what it actually takes. Get in touch.
04Technical DNA
The tools I actually reach for
No percentage bars or star ratings — those measure nothing. This is simply what I work with, with the handful I use every day marked.
Frontend
Component architecture, state, and interfaces that hold up on a phone.
Angular — Part of my day-to-day work
TypeScript — Part of my day-to-day work
RxJS — Part of my day-to-day work
Angular Signals
React
Next.js
JavaScript
HTML5
CSS3
SCSS / Sass
Backend
APIs, business logic, authentication and integration work.
Node.js
NestJS
Express.js
C#
.NET
ASP.NET Web API
REST APIs — Part of my day-to-day work
Databases
Schema design, queries, and the data workflows an app runs on.
PostgreSQL
MySQL
MongoDB
Tooling
Everything around the code.
Git — Part of my day-to-day work
Responsive design
Accessibility
Part of my day-to-day work. Everything else is something I build with — it is not a claim of mastery in each one.
05Selected work
Things I've built
Four projects, each with the problem it addresses and what it actually does. The visuals are mockups drawn to illustrate the interface, not screenshots.
Illustrative interface mockup — not a screenshot
01Sep — Dec 2025
Scrap Price Estimator
A multi-page site that gives people an estimated scrap price for the products they select.
The problem
Scrap pricing is opaque. Anyone with material to sell has to call around, describe what they have, and take the first number they're given — with no way to sanity-check it first.
What it does
A guided flow: pick a product category, describe the item, get an estimate back. The pricing logic lives server-side so rates can be updated without touching the frontend, and the whole thing is built to be used on a phone standing in a yard.
Category-driven product selection
Server-side pricing logic, editable without a redeploy
Mobile-first flow with a shareable estimate
Illustrative interface mockup — not a screenshot
02Nov 2023 — Jan 2024
Data Extractor Tool
An internal tool for creating, reading, updating and deleting structured records at volume.
The problem
Operational data tends to live in spreadsheets that three people edit at once. There's no validation, no history, and no safe way to correct a thousand rows after someone pastes the wrong column.
What it does
A record-management interface backed by a relational schema. Records are created, edited and removed through a validated form layer rather than free-text cells, so the data stays consistent as the table grows.
Full create / read / update / delete workflow
Validated forms over a relational schema
Searchable, paginated record table
My roleBuilt the Angular frontend, the ASP.NET backend and the MySQL schema behind it.
Angular
ASP.NET
MySQL
TypeScript
Illustrative interface mockup — not a screenshot
03
IoT Management App
A platform for managing connected devices, with a 3D interface and scroll-driven navigation.
The problem
Device fleets are usually presented as a flat table of serial numbers. That tells you what exists, but not where anything sits in relation to anything else — which is the thing you actually need when something goes offline.
What it does
A spatial interface instead of a list: devices rendered as connected nodes you can move through, with status surfaced visually and scroll used to navigate between groups rather than to page through rows.
Interactive 3D device view
Scroll-driven navigation between device groups
Per-device status and management actions
Illustrative interface mockup — not a screenshot
04
Bagify
An admin application for managing a product catalogue — creating, updating and removing items.
The problem
Small retailers get handed a storefront and no sensible way to run it. Adding a product becomes a support ticket, and the catalogue drifts out of date because changing it is somebody else's job.
What it does
A catalogue admin built for the person who actually runs the shop: add an item, change a price, pull something that's out of stock. Plain forms, immediate feedback, nothing that needs a manual.
Product create, update and delete
Catalogue listing with search
Form-level validation and confirmation states
Also built
Trending MoviesFetches and displays the day's top 20 trending films from TMDB.TMDB API · REST
SkyboardA live dashboard that pulls weather, traffic, prayer times and rates into one screen.
Illustrative interface mockup — not a screenshot01Intro
One screen instead of six apps.
Skyboard is a live dashboard. It aggregates the handful of things you check anyway — the weather, how bad the traffic is, when the next prayer is, what the rates are doing — and puts them on a single screen that stays open.
02Problem
The information is fine. The gathering is the problem.
None of this data is hard to find. It's just scattered. Four apps, four load times, four different ideas of what a card should look like — repeated every morning, and again before you leave the office.
Each source has its own app, refresh rate and failure mode
No single view of the things that actually affect the day
Checking is a habit, so friction compounds daily
03Product
A board, not a feed.
Every source is a tile. Tiles are sized by how much attention they deserve rather than by how much data they return, and the board is designed to be glanceable from across a room — large numerals, high contrast, no interaction required to read it.
Tile-based grid, each tile owning one data source
Readable at a distance: large numerals, strong contrast
Passive by default — no clicking needed to get the answer
04Features
What each tile does.
The tiles share a contract — fetch, cache, render, degrade — but each one presents its data the way that data is actually used.
Weather: current conditions plus the part of the forecast that changes plans
Traffic: live conditions on the routes that matter to you
Prayer times: next prayer surfaced, full day available
Rates: current values with direction of movement
05Architecture
The frontend never talks to a third party.
Every external source is fetched server-side, normalised into one internal shape, and cached on an interval that suits that source. The browser only ever sees a single endpoint returning a predictable payload. That keeps API keys off the client, stops four different rate limits from becoming the frontend's problem, and means a slow upstream degrades one tile instead of the whole board.
Server-side aggregation — keys and rate limits stay on the server
Per-source cache intervals matched to how fast each one changes
One normalised payload for the client, whatever the upstream shape
Per-tile failure: one dead source doesn't take the board down
06Status
Where it stands.
Skyboard is a working build. The architecture below is a description of how it is put together, not a claim about scale or traffic — if you want to talk through how it was approached, or want something similar built around your own data, the next section has every way to reach me.
Scroll
07How I build
One system, four layers
A request leaves the interface, is validated at the API, resolved by the domain layer, answered by the database, and travels back the same way. Designing those four together is the whole job.
01
Interface
Angular · React · Next.js
components · state · forms
02
API
NestJS · Express · ASP.NET
routing · validation · auth
03
Domain logic
Services · rules · jobs
business rules · scheduling
04
Database
PostgreSQL · MySQL · MongoDB
schema · queries · indexes
response
Illustrative reference architecture. It shows how these layers generally fit together — it is not a diagram of any specific client system.
One shape, both ends
The types that describe a response live in one place and are used by the API and the frontend alike. When the shape changes, the compiler finds every caller before a user does.
typescript · shared interfaces
Validate at the boundary
Input is checked where it enters the system — in the form for feedback, and again at the API because the form is not a security control. Bad data gets a clear message, not a stack trace.
client + server validation
Fail in one place, not everywhere
Requests fail. The question is whether one slow upstream degrades a single panel or takes the whole screen down. Errors are caught close to where they happen and surfaced as state, not as a blank page.
error boundaries · fallback states
Phone first, properly
Layouts are designed for small screens rather than scaled down to them. Touch targets, readable type, no hover-only information, and keyboard access throughout.
responsive · wcag · keyboard
Ship less JavaScript
Render on the server where it makes sense, lazy-load what isn't needed yet, size images for the slot they land in, and keep animation off the main thread. Fast is a feature.
ssr · code-splitting · lazy media
Leave it readable
Clear structure, meaningful names and a README that explains how to run and deploy it. You should be able to hand the project to another developer without a phone call.
docs · conventions · handover
08Journey
Where I work, and how
The timeline lists only what I can state plainly. The principles beside it are how I approach a project, whoever it's for.
Current role
Full-Stack DeveloperQuduratech
Hyderabad, India
Full-stack development on the company's web applications — building interfaces, the APIs behind them, and the data they run on.
Education
EngineeringCMR Technical Campus
GPA 8.02
How I work
Understand the workflow first
Before writing anything I want to see how the work is done today — including the spreadsheet everyone pretends isn't load-bearing. The data model should fit the job, not the other way round.
Build it so it can be changed
Most of a project's life happens after launch. Clear component boundaries, typed interfaces and readable code mean the next change takes an afternoon rather than a rewrite.
Handle the unhappy path
Empty states, slow networks, failed requests and bad input are the normal case, not the exception. An interface that only works when everything goes right isn't finished.
Stay reachable
Short feedback loops, plain-language updates, and no disappearing for two weeks. You should always know what state your project is in.
09Contact
Have an ideaworth building?
Contact Altaf Shaik
Tell me what you're trying to build or what's broken. A couple of sentences is enough to start — I'll come back with what it would actually take, and an honest answer if it isn't something I should be doing.
