3 Taking an app from concept to code

The chapter recommends breaking app development into six stages:

1. State the concept: Describe the problem or app idea succinctly.
2. Define the requirements: Decide what the app must do and what it will not do.
3. Visualize the user experience: Sketch or mock up how users will interact with the app.
4. Brainstorm implementation: Identify frontend, backend, configuration, and logic flow.
5. Write code: Implement the app.
6. Iterate: Test, refine, and improve the app based on use and feedback.

Requirements turn a high-level concept into concrete goals. They describe what stakeholders need the app to do, such as accepting a numeric value, selecting compatible units, and displaying the converted result. Good requirements avoid implementation details like specific widgets or technologies, keeping the focus on user and stakeholder needs rather than on how the solution will be built.

The chapter builds a unit converter app. Its concept is a Streamlit app that lets users effortlessly convert between units of measurement such as distance, mass, and time. The app supports conversions within systems, such as meters to centimeters, and across systems, such as feet to meters.

Defining what is out of scope prevents misunderstandings and keeps the project manageable. For the unit converter, features like usage tracking, logging, visualizations, and currency conversions were excluded. Currency conversions were considered out of scope because exchange rates change frequently and would require an external data source or API.

Working backward from the user experience keeps the user’s needs central to the design. By sketching the UI first, you can identify what inputs, outputs, and interactions the app needs before worrying about code. In the unit converter, the mock UI included a quantity selector, a numeric input, from-unit and to-unit dropdowns, and an area to display the conversion result.

Instead of storing a conversion factor for every pair of units, the app chooses one standard unit for each quantity. For example, meters can be the standard unit for length. To convert from unit X to unit Y, the app first converts X to the standard unit, then converts the standard unit to Y. This means the app only needs to store one conversion factor per unit.

The configuration file keeps all supported quantities, units, abbreviations, and conversion factors in one obvious place. This makes the app easier to maintain. To add a new unit, the developer only needs to add an entry to the configuration instead of searching through UI or backend code. The rest of the app reads from the configuration instead of hard-coding specific units like meters, pounds, or seconds.

The chapter introduces several common Streamlit widgets and layout tools:

• st.radio for selecting one option from a list
• st.sidebar for placing controls in a left-side panel
• st.title for displaying the app title
• st.text_input for collecting a text value
• st.selectbox for dropdown menus
• st.columns for side-by-side layout
• st.button for triggering an action
• st.metric for displaying important numeric output
• st.number_input for numeric inputs with bounds and step controls
• st.checkbox for optional user choices

The backend exposes three main actions to the frontend:

• List quantities: Return the supported quantity names, such as Mass, Length, and Time.
• List units: Given a quantity, return the units available for that quantity.
• Convert value: Given a quantity, from-unit, to-unit, and value, return the converted result.

This separation keeps the frontend focused on user interaction and the backend focused on conversion logic.

The Convert button was removed to make the app feel more immediate and intuitive. Since Streamlit reruns the script when inputs change, the app can always display the current conversion result based on the selected quantity, units, value, and rounding options. This eliminates an unnecessary click and lets users see updated results instantly.