A useful first project is small enough to finish and clear enough to explain. If you are learning Ethereum development in Tunisia, you do not need to begin with a token launch or a complicated financial application. Begin with one action a person needs to perform.
Choose one problem and one user
Write a sentence that describes the user and their task. For example: a workshop organizer wants participants to check whether a sample attendance credential was issued by the organizer. Keep the example fictional and use test data.
Then explain why shared verification helps. If a conventional database solves the problem more simply, build that first or choose a different learning exercise. The aim is to understand the trade-off, rather than attach a blockchain to every feature.
Learn the parts your prototype needs
Ethereum applications can combine a familiar web interface with smart contracts. A contract is a program deployed on the network; your interface can read information and ask a user to submit a transaction.
For a first exercise, draw the boundary between the interface, wallet and contract. Decide which information belongs in each place. Avoid placing personal details or secrets on a public blockchain. Public visibility and difficult-to-reverse writes make data choices part of the design.
- Read the introductory developer documentation.
- Identify the few contract functions the application needs.
- Describe what the user must approve and what it may cost.
- Define what should happen if the transaction is rejected or fails.
Build and test before using real value
Use a local development network to iterate, then an appropriate public testnet to check the full interaction. Ethereum’s network guide currently identifies Sepolia for application testing and Hoodi for validator-related testing. Recheck that guide before choosing a network because testnet support changes.
Keep testing accounts separate from accounts holding real assets. Use fictional credentials, sample records and test balances. A working demonstration does not establish that a contract is secure enough for production.
Include the awkward cases
The happy path is only one part of a useful prototype. Try the same action twice. Cancel a wallet request. Enter the wrong account. Refresh the page while an action is pending. Check what a visitor sees when they have no wallet installed.
For the sample credential project, decide who can issue and revoke a record, whether the same record can be issued twice and how the interface distinguishes a missing record from a network error. Tests should verify those rules rather than only repeat implementation details.
Prepare a demonstration another person can follow
A strong demonstration starts with the user’s problem, shows one complete action and ends with the outcome. Explain what works, what remains experimental and which assumptions you made. Publish setup steps so a collaborator can run the prototype.
Before a future ETH Tunis workshop or project session, bring a concise README, a working test environment and a specific question for feedback. The session format is still being prepared; this roadmap is an independent preparation guide, not an event application requirement.
Resources & further reading
Primary documentation and references for further learning. Linking to a resource does not imply a partnership.
Something to contribute?
Propose a workshop, share your project or tell us how you’d like to take part.
Contribute to ETH Tunis