Forem: Patrick Offei Danso

Quick Prototyping

Patrick Offei Danso — Thu, 01 Jan 2026 08:47:02 +0000

When I'm prototyping, my goal is simple: prove the idea works before I fall in love with it.
Not perfect code. Just enough to learn something.

This is hard for me, especially because I enjoy clean design and solid architecture. Left unchecked, I'll spend hours on theme, spacing, naming, or edge cases no user will ever hit. Rapid prototyping is how I fight that instinct.

Start with clarity

Before I open an editor, I try to answer a few questions in plain language:

What problem am I solving?
Who is this for?
What is the one thing this app must do well?
How do I get users?

If I can't explain the product in one or two sentences, I'm not ready to build. Code won't save unclear thinking.

I usually write a very small PRD. Just the goal, the main user flow, and how I'll know it's working. This alone prevents a lot of wasted effort.

Build the skeleton first

I don't start by building features. I start by building structure.
That means:

routing
basic layout
data flow
folder structure
naming conventions

No business logic or abstractions yet. This gives the project a backbone. Once that's in place, everything else moves faster and stays less chaotic.

Start from a bootstrapped template

I rarely start from a blank project anymore.
A good starter or template already has the boring parts done:

project structure
auth or basic user model (even if unused)
linting, formatting, env setup
routing and layout
basic config

This saves hours on day one and reduces decision fatigue.

The key is not to fight the template. Remove what you don't need, keep what helps, and move on. We are focused on speed, not elegance. If you're building fast, a slightly opinionated setup is better than endless setup freedom.

Use a UI library. Always.

I no longer debate this.
Buttons, inputs, modals, tables, … I don't want to think about them. A good UI library removes hundreds of tiny decisions that add no value at the prototype stage.
This doesn't mean your product will look generic forever. It just means you're not wasting time solving solved problems.

I remind myself, "Users care about value, not whether my border radius is unique."

Fight the urge for pixel perfection

This is where I struggle the most.
I'll adjust spacing. Then colors. Then font weights. Then responsiveness. Suddenly, two hours are gone and nothing meaningful changed.
So I now force a rule:

Is this blocking user understanding? Fix it.
Is this cosmetic? Ignore it.

Pixel perfection comes after validation, not before.
Design polish is a reward for proven demand.

Don't build everything at once, structure for change

I don't try to ship every possible future feature in version one. Instead, I structure the project so adding things later doesn't feel painful.
That means I don't build:

plugin systems
event buses
heavy domain layers

But I do:

keep boundaries clear between features
name files and functions based on what they do, not what they might become
keep functions small and replaceable
avoid hard-coded assumptions that lock me into one flow
isolate parts that may change (auth, payments, integrations)
leave short comments where future extensions are obvious

I want to be able to add new features, external services/providers, and even different tools without needing a rewrite.

Choose what you already know

This is underrated.
Shiny tech is fun, but familiarity wins when speed matters. When I use tools I already understand:

I debug faster
I write fewer bugs
I make better decisions

You can always rewrite. You can't get back wasted time.

Where AI actually helps me

AI is not where I start. It's where I accelerate.
Once the structure exists, AI becomes very useful:

drafting PRDs
refining flows
generating boilerplate
writing tests
spotting bugs

But only if I have a clear workflow.
An example flow that works for me:

Use one tool to clarify the idea and specs
Use a coding assistant to help implement parts faster
Use a bug-focused tool to review and catch issues

I also keep:

rules
guidelines
project context
folder structure docs

This makes AI responses more accurate and less chaotic.

Documentation is leverage

Light documentation saves heavy refactors.
I usually keep:

a PRD
a simple flow diagram
a structure doc (folders, APIs, contracts)
a list of assumptions

Validate early, then decide

Once the prototype works end-to-end, I stop building.
I put it in front of users. I watch them. I listen.
Only after validation do I decide:

polish UI
refactor architecture
add features
or kill the idea

Fast prototyping isn't about being sloppy.
It's about being honest with time.

Build the smallest thing that can teach you something real.
Everything else is noise.

How to Create an Executable .jar file for JavaFX using Maven

Patrick Offei Danso — Sat, 02 Sep 2023 15:58:47 +0000

Introduction

You’re probably in a situation where you’ve written a great piece of software, tested it rigorously, and are now facing the daunting task of turning your masterpiece into something that can be executed with a double-click.

When I first delved into this, I found myself stuck in a labyrinth of outdated tutorials, confusing stack overflow answers, and documentation that seemed like it was written for someone with years of experience in Java deployment. I was searching for a straightforward guide to creating an executable .jar file and the journey was anything but simple.

That’s why I decided to write this article, to save you the hours of headache that I had to go through. Whether you’re a beginner or someone who just needs a refresher, this step-by-step guide is for you.

This tutorial will focus on using Java 11 or later, JavaFX, and Maven for dependency management.

Pre-requisites

Your JavaFX application can run from the command line or IDE, but nothing happens when you double-click or open the .jar build.
You are using Java Development Kit (JDK) 11 or later
You are using Maven for dependency management.

Building the Executable .jar File

1. Create a New ‘Main’ Class

Before we delve into creating the executable .jar file, you need to make a slight modification in your code structure. You’ll need to create a new class that will run the main function of your existing main class. This is particularly important for JavaFX applications.

Here’s how you do it:

Main.java (New Class)
Create a new Java class in your project and name it Main. Add the following code to this class:

package your.package.name;

public class Main {
 public static void main(String[] args) {
 App.main(args);
 }
}

This class simply calls the main function of your existing App class.

App.java (Previous Main Class)
In case you’re wondering, here’s what your existing App class might look like:

package your.package.name;

import java.io.IOException;
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.stage.Stage;
import javafx.fxml.FXMLLoader;
import javafx.scene.Parent;

/**
 * JavaFX App
 */
public class App extends Application {
  private static Scene scene;

  @Override
   public void init() {
   }

   @Override
   public void start(Stage stage) throws IOException {
   scene = new Scene(loadFXML("app"), 800, 600);
   scene.getStylesheets().add(getClass().getResource("styles.css").toExternalForm());
   stage.setScene(scene);
   stage.setTitle("My App");
   stage.show();
   }

   static void setRoot(String fxml) throws IOException {
     scene.setRoot(loadFXML(fxml));
   }

   private static Parent loadFXML(String fxml) throws IOException {
     FXMLLoader fxmlLoader = new FXMLLoader(App.class.getResource(fxml + ".fxml"));
     return fxmlLoader.load();
   }

   public static void main(String[] args) {
     launch();
   }

}

With this new Main class in place, you’ve set the stage to create an executable .jar file that will launch your JavaFX application.

2. Update Your Maven pom.xml File

The next step is to include the Maven Shade Plugin in your pom.xml configuration file. This plugin is essential for packaging the artifact in an uber-jar, including its dependencies and resources, and thus makes it executable. Here’s how to do it:
Open your pom.xml file and add the following code snippet for the Maven Shade Plugin:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>LATEST VERSION HERE</version>
    <executions>
      <execution>
        <phase>package</phase>
        <goals>
          <goal>shade</goal>
        </goals>
        <configuration>
          <transformers>
            <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
              <mainClass>your.package.name.Main</mainClass>
            </transformer>
          </transformers>
        </configuration>
      </execution>
    </executions>
</plugin>

Ensure you replace your.package.name.Main with the fully qualified name of your new Main class and LATEST VERSION HERE with the latest version of the Maven Shade Plugin, for example: 3.5.0.

Your Final pom.xml Should Look Like This:

<!-- ... existing content ... -->
<build>
  <plugins>
    <!-- ... existing plugins ... -->
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-shade-plugin</artifactId>
      <version>3.5.0</version>
      <executions>
        <execution>
          <phase>package</phase>
          <goals>
            <goal>shade</goal>
          </goals>
          <configuration>
            <transformers>
              <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                <mainClass>com.example.Main</mainClass>
              </transformer>
            </transformers>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>
<!-- ... existing content ... -->

3. Building and Testing the .jar File

Cleaning the Project: Open your terminal and navigate to your project directory. Run the following command to clean any previous builds:

mvn clean

Testing the New Main Class: Before proceeding further, ensure that your new Main class can run the application correctly. You can do this by running your project from your IDE or using the Maven command mvn javafx:run.

Building the .jar File: If everything works as expected, go back to your terminal and run:

mvn install

This command will compile your code, download any required dependencies, and package everything into a .jar file.

Locating the .jar Files: After running mvn install, you’ll find two .jar files in the target directory of your project:

your-artifact-id-version.jar
your-artifact-id-version-shaded.jar The second .jar file, which ends in -shaded, is the one you’re interested in. This is the executable .jar file that includes all your project’s dependencies.

Now navigate to the target directory in your project folder and double-click the .jar file that ends in -shaded. Your JavaFX application should launch and run as expected, confirming that you’ve successfully created an executable .jar file.

You Did It! 🎉**

Congratulations, you’ve just built an executable .jar file for your JavaFX application! You can now distribute this .jar file, allowing users to run your application with just a double-click — No technical fuss involved.
For a step-by-step visual guide, you can also check out this helpful YouTube video.