The production model pipeline is now complete and verified.
Now build the Streamlit website for the Laptop Price Prediction project.
IMPORTANT:
The website must use the existing production interface:
from src.predict import predict_laptop_price
Do NOT recreate any feature-engineering logic inside the Streamlit app.
Do NOT retrain the model.
Do NOT modify notebooks 01–06.
The website should act as a polished Laptop Fair-Price Analyzer, not just a plain regression demo.
---
1. Install Streamlit
Add Streamlit to the existing laptop_price environment and update environment.yml so the environment remains reproducible.
Verify that Streamlit imports successfully.
---
2. Create the application
Create:
app.py
The application should load the existing saved model through the functions already provided in src.predict.
Do not load or manipulate the joblib artifact manually if src.predict already provides the correct loading interface.
Use the cached model-loading mechanism already implemented.
---
3. Page design
Use:
st.set_page_config(
page_title="Laptop Fair-Price Analyzer",
page_icon="💻",
layout="wide"
)
The page should feel clean, modern, and professional.
Title:
Laptop Fair-Price Analyzer
Subtitle:
Estimate the expected price of a laptop from its specifications using a machine-learning model trained on historical laptop data.
Also include a small explanation:
> This model estimates a reference/fair price based on hardware specifications. It does not fetch current prices from Amazon, Flipkart, or other retailers.
Do not make exaggerated claims such as:
- “exact market price”
- “best price”
- “guaranteed fair value”
---
4. Input form
Use a Streamlit form.
Organize inputs into logical sections.
Laptop basics
- Company
- Laptop Type
- RAM
- Weight
- Operating System
Processor and graphics
Storage
Display
- Screen size in inches
- Resolution
- Touchscreen
- IPS panel
---
5. Use model-supported options
Import and use:
get_input_options()
from the production prediction module if available.
Use these values to populate dropdowns for:
- company
- laptop type
- CPU
- GPU
- operating system
Do not manually hard-code duplicate lists if the production module already supplies them.
For the first version of the website, prefer dropdown/selectbox inputs over unrestricted free text.
This is important because the model is most reliable for categories represented in its training data.
---
6. User-friendly RAM options
If the metadata/input-options expose the observed RAM values, use those.
Otherwise use only valid values represented in the training data.
For example:
2 GB
4 GB
6 GB
8 GB
12 GB
16 GB
24 GB
32 GB
64 GB
Display GB to the user but send a numeric value to predict_laptop_price().
---
7. Storage inputs
Let the user select realistic SSD/HDD values.
Examples may include:
SSD:
0 GB
128 GB
256 GB
512 GB
1024 GB
HDD:
0 GB
500 GB
1000 GB
2000 GB
Prefer model metadata / observed training values if available rather than inventing unsupported categories.
The prediction function must receive numeric GB values.
---
8. Display resolution
Make resolution easy for users.
Prefer a dropdown containing common resolutions supported by the dataset, such as values discovered from the training data.
Display:
1920 × 1080
1366 × 768
2560 × 1440
3840 × 2160
...
Internally split the chosen resolution into:
resolution_width
resolution_height
Do NOT ask ordinary users to manually enter X_res and Y_res separately unless necessary.
---
9. Touchscreen and IPS
Use checkboxes/toggles for:
Convert them into proper Python bool values before calling the prediction function.
---
10. Weight and screen size
Use suitable numerical inputs.
Weight:
- display unit: kg
- sensible bounds based on training data
Screen size:
- display unit: inches
- sensible bounds based on training data
Use the ranges returned by metadata/input-options where possible.
---
11. Prediction
When the user clicks:
Estimate Price
construct ONE raw specification dictionary matching exactly what:
predict_laptop_price(specs)
expects.
Example structure:
{
"company": ...,
"type_name": ...,
"ram_gb": ...,
"weight_kg": ...,
"inches": ...,
"resolution_width": ...,
"resolution_height": ...,
"touchscreen": ...,
"ips": ...,
"cpu": ...,
"gpu": ...,
"os": ...,
"ssd_gb": ...,
"hdd_gb": ...
}
Do not derive:
- PPI
- CPU generation
- CPU type
- CPU brand
- GPU tier
- grouped company
inside app.py.
Those MUST continue to be produced by the existing production feature module.
---
12. Prediction result display
Show the prediction prominently.
For example:
Estimated Price
₹48,000
Use Indian-style currency formatting if practical.
Also show smaller explanatory text such as:
> This is the model's estimated reference price based on laptops with similar specifications in the training data.
Do NOT call it the exact current retail price.
---
13. Model reliability information
Under the prediction display, include:
Model performance on unseen evaluation data
- Typical absolute error: about ₹8,700
- Median percentage error: about 12%
- Performance is generally weaker for unusual premium laptops and workstations.
These numbers must come from the saved metadata rather than being independently hard-coded if the metadata contains them.
Do NOT write:
95% confidence interval
and do NOT present ±12% as a statistically calibrated confidence interval.
You may display:
> Historically, half of predictions had a percentage error of roughly 12% or less.
or an equivalent accurate explanation.
---
14. Optional advertised-price comparison
Add an OPTIONAL field:
Seller / Listed Price
The user may leave this blank.
If provided, compare it with the model prediction.
For example:
Estimated model price: ₹80,000
Listed price: ₹92,000
₹12,000 above the model estimate
15% above the model estimate
or:
₹7,000 below the model estimate
Use neutral wording.
Do NOT declare:
- “good deal”
- “bad deal”
- “overpriced”
- “buy this”
because the model does not account for every real-market factor.
Say instead:
> The listed price is 15% above this model's estimate.
This turns the project into a useful price-comparison tool without overstating what the model knows.
---
15. Warnings
predict_laptop_price() may return warnings or raise InvalidSpecError.
Handle both properly.
If an InvalidSpecError occurs:
st.error(...)
with the useful error message.
If prediction warnings are returned, display them using:
st.warning(...)
Do not hide model warnings.
---
16. Explain what the model uses
Add an expandable section:
How does this work?
Briefly explain that the model uses features including:
- company
- laptop type
- RAM
- weight
- CPU characteristics
- GPU class
- SSD/HDD capacity
- screen size
- resolution / pixel density
- touchscreen
- IPS
- operating system
Mention that feature engineering derives information such as CPU generation, CPU class, GPU tier, and PPI automatically.
Keep it understandable to a non-ML user.
---
17. Model limitations section
Add another expandable section:
Limitations
Include:
- dataset is historical, not live retailer data;
- current discounts and promotions are not considered;
- laptop age/condition is not modeled;
- exact model/build quality may contain information not represented in the dataset;
- prediction errors are larger for very expensive and unusual laptops;
- this is an estimated reference price, not a guaranteed market price.
---
18. Sidebar
Use the sidebar for concise project/model information.
Include something like:
Model
XGBoost Regressor
Training laptops
1,273
Evaluation
Log-price R² ≈ 0.916
MAE ≈ ₹8,700
Median percentage error ≈ 12%
Read these values from model_metadata.json whenever practical.
Also display:
Applied AI & Data Science Project
Do not clutter the sidebar.
---
19. UI quality
Please make the interface polished.
Use:
- columns where useful
- sensible spacing
- clear labels
- tooltips/help text where terminology may confuse users
- formatted INR amounts
- a spinner while predicting if appropriate
Avoid excessive emojis and decorative elements.
Do not add unnecessary animations.
---
20. Architecture rule
The architecture must remain:
Streamlit UI
↓
predict_laptop_price()
↓
src/features.py
↓
saved preprocessing + XGBoost pipeline
↓
prediction
NOT:
Streamlit UI
↓
duplicate feature engineering inside app.py
This is a hard requirement.
---
21. Test the website
Before reporting completion:
- Start Streamlit locally.
- Confirm the page loads without exceptions.
- Run at least several different laptop configurations.
- Compare one prediction against direct
predict_laptop_price() output and verify that they are identical. - Test:
- Mac laptop
- budget Windows notebook
- gaming laptop
- laptop with no HDD
- touchscreen laptop
- Verify invalid inputs are handled cleanly.
- Verify seller-price comparison calculations.
- Verify the app doesn't retrain or reload the model on every interaction.
---
22. Add website tests where reasonable
Do not duplicate the existing model test suite.
Add lightweight tests only for website-specific helper functions if needed, such as:
- INR formatting
- resolution parsing
- listed-price comparison
Do not test Streamlit's visual appearance through brittle hacks.
---
23. Update README
Add:
Run the web app
conda activate laptop_price
streamlit run app.py
Describe what the website does.
Do not remove the existing ML/project documentation.
---
24. Final report
When finished report:
- files created/modified;
- Streamlit version installed;
- exact command to run the website;
- whether the site launched successfully;
- one example prediction through the site;
- confirmation that the site's prediction exactly matches
predict_laptop_price(); - confirmation that no feature engineering is duplicated inside
app.py; - any warnings/limitations the user should know;
- updated project structure.
Do NOT deploy publicly yet.
First build and verify the local website so I can review it.