// man nepal-tech
Frequently asked questions
The general questions first, then the ones specific to each area of work.
General
Working code in a repository (or a zip) with a README that explains how to install and run it, the evidence your brief asks for — screenshots, outputs, test results — and a written report or explanation if your rubric requires one.
Python, Java, C and C++, JavaScript and TypeScript, React, Node, Django, Laravel, Flutter, SQL and NoSQL databases, pandas and scikit-learn, R, MATLAB and Simulink, Arduino and ESP32, networking tools such as Packet Tracer, and cloud and DevOps tooling. If your stack is not listed, ask — the brief decides.
We read the brief first, then quote a fixed price and delivery date in writing. The price depends on scope, stack and deadline — not on how many times you need to ask a question. A small advance confirms the order.
That is the point of the tested handover. Dependencies are pinned, paths are relative, and the code is run on a clean environment against your test cases before it is sent.
Yes. Every delivery can include a walkthrough call, and Technical Viva Prep is a service of its own — likely questions, answers in your own words, and a mock viva.
Yes. Assignment Nepal Tech is Assignment Byte's programming and data line, with the same WhatsApp number and email. This site exists so coding and data work has a place of its own.
Your brief, code, data and personal details are never shared with third parties, never reused for another client and never posted publicly. Anything shown on Instagram is anonymised.
Languages
Yes. Tell us the version and toolchain — Python 3.10 vs 3.12, Java 17 vs 21, gcc vs MSVC — and we build and test against exactly that. If the brief does not say, we ask before starting.
That is the normal case. We keep your file structure, function signatures and class names intact, because autograders and markers look for them.
Web & Apps
Either. Most coursework only needs to run locally from a README; if your module wants a live demo URL, say so and we include a deployment in the quote.
Yes — the stack in your brief is the stack we use. We do not swap in something more convenient for us.
Data
The notebook or scripts that produced every number, so the analysis can be re-run end to end. Results pasted into a report without the code behind them are hard to defend.
No. Data is used only for your task, never shared or reused, and deleted on request once the work is signed off.
Systems
Usually not — we build in our own environment and hand over the configuration, infrastructure code and evidence. If the brief insists on your account, we agree scoped access first. We never ask for your university login.
Yes. Evidence is captured as the work is done, labelled to match the brief's tasks, so the report and the submission line up.
Engineering
We write and test the firmware and provide wiring diagrams and a bill of materials. For physical builds we can work with the kit you have over a video call, or deliver a simulation if the brief allows it.
Tell us your release and toolboxes and we test against them. We avoid functions that only exist in toolboxes you do not have.
Projects
For capstones that is the default: proposal, design, build and report are delivered in stages that line up with your supervisor meetings, so feedback lands before the next stage.
Yes — SRS, UML and design documents, test plans and the final report, written to match the code that was actually built.
Support
Yes, and that is usually better for you — we keep your structure and style, fix what is broken and explain each change so you can talk about it.
A screen-shared call on Google Meet or Zoom at a time you book. You drive, we diagnose, and you end the call with working code and a note of what caused the problem.
./send-brief
Question not here?
Ask it on WhatsApp — a real reply from the people who would do the work.